[Bug c/28770] New: one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[Bug c/28770] New: one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[etienne_lorrain at yahoo dot fr]

Unlike with GCC-3.*, building GCC-4.1.1 PPC crosscompiler from a bootstrapped
native GCC-4.1.1 and binutils-2.17 on cygwin fails because of a small error.
Using a new and up to date Cygwin install.

xgcc -v (after fix) gives:
Using built-in specs.
Target: powerpc-ibm-eabi
Configured with: ../gcc-4.1.1/configure --prefix=/cygdrive/c/cygwin-gcc/local
--program-prefix=x --target=powerpc-ibm-eabi --with-cpu=440 --with-newlib
--enable-languages=c
Thread model: single gcc version 4.1.1 

The error message is:
........
../../gcc-4.1.1/gcc/unwind-c.c:1: warning: -msoft-float and -mlong-double-128
no t supported
rm -f ./libgcc.a 
powerpc-ibm-eabi-ar  rc ./libgcc.a libgcc/./_muldi3.o libgcc/./_negdi2.o
libgcc/ ./_lshrdi3.o libgcc/./_ashldi3.o libgcc/./_ashrdi3.o libgcc/./_cmpdi2.o
libgcc/. /_ucmpdi2.o libgcc/./_floatdidf.o libgcc/./_floatdisf.o
libgcc/./_fixunsdfsi.o l ibgcc/./_fixunssfsi.o libgcc/./_fixunsdfdi.o
libgcc/./_fixdfdi.o libgcc/./_fixun ssfdi.o libgcc/./_fixsfdi.o
libgcc/./_fixxfdi.o libgcc/./_fixunsxfdi.o libgcc/./ _floatdixf.o
libgcc/./_fixunsxfsi.o libgcc/./_fixtfdi.o libgcc/./_fixunstfdi.o l
ibgcc/./_floatditf.o libgcc/./_clear_cache.o libgcc/./_enable_execute_stack.o
li bgcc/./_trampoline.o libgcc/./__main.o libgcc/./_absvsi2.o
libgcc/./_absvdi2.o l ibgcc/./_addvsi3.o libgcc/./_addvdi3.o
libgcc/./_subvsi3.o libgcc/./_subvdi3.o l ibgcc/./_mulvsi3.o
libgcc/./_mulvdi3.o libgcc/./_negvsi2.o libgcc/./_negvdi2.o l ibgcc/./_ctors.o
libgcc/./_ffssi2.o libgcc/./_ffsdi2.o libgcc/./_clz.o libgcc/./ _clzsi2.o
libgcc/./_clzdi2.o libgcc/./_ctzsi2.o libgcc/./_ctzdi2.o libgcc/./_pop
count_tab.o libgcc/./_popcountsi2.o libgcc/./_popcountdi2.o
libgcc/./_paritysi2. o libgcc/./_paritydi2.o libgcc/./_powisf2.o
libgcc/./_powidf2.o libgcc/./_powixf
2.o libgcc/./_powitf2.o libgcc/./_mulsc3.o libgcc/./_muldc3.o
libgcc/./_mulxc3.o libgcc/./_multc3.o libgcc/./_divsc3.o libgcc/./_divdc3.o
libgcc/./_divxc3.o lib gcc/./_divtc3.o libgcc/./_eprintf.o
libgcc/./__gcc_bcmp.o libgcc/./_divdi3.o lib gcc/./_moddi3.o
libgcc/./_udivdi3.o libgcc/./_umoddi3.o libgcc/./_udiv_w_sdiv.o
libgcc/./_udivmoddi4.o libgcc/./_pack_sf.o libgcc/./_unpack_sf.o
libgcc/./_addsu b_sf.o libgcc/./_mul_sf.o libgcc/./_div_sf.o
libgcc/./_fpcmp_parts_sf.o libgcc/. /_compare_sf.o libgcc/./_eq_sf.o
libgcc/./_ne_sf.o libgcc/./_gt_sf.o libgcc/./_g e_sf.o libgcc/./_lt_sf.o
libgcc/./_le_sf.o libgcc/./_unord_sf.o libgcc/./_si_to_ sf.o
libgcc/./_sf_to_si.o libgcc/./_negate_sf.o libgcc/./_make_sf.o libgcc/./_sf
_to_df.o libgcc/./_thenan_sf.o libgcc/./_sf_to_usi.o libgcc/./_usi_to_sf.o
libgc c/./_pack_df.o libgcc/./_unpack_df.o libgcc/./_addsub_df.o
libgcc/./_mul_df.o li bgcc/./_div_df.o libgcc/./_fpcmp_parts_df.o
libgcc/./_compare_df.o libgcc/./_eq_ df.o libgcc/./_ne_df.o libgcc/./_gt_df.o
libgcc/./_ge_df.o libgcc/./_lt_df.o lib gcc/./_le_df.o libgcc/./_unord_df.o
libgcc/./_si_to_df.o libgcc/./_df_to_si.o li bgcc/./_negate_df.o
libgcc/./_make_df.o libgcc/./_df_to_sf.o libgcc/./_thenan_df .o
libgcc/./_df_to_usi.o libgcc/./_usi_to_df.o libgcc/./tramp.o libgcc/./darwin-
ldouble.o libgcc/./eabi.o libgcc/./unwind-dw2.o libgcc/./unwind-dw2-fde.o
libgcc /./unwind-sjlj.o libgcc/./gthr-gnat.o libgcc/./unwind-c.o 
make[4]: powerpc-ibm-eabi-ar: Command not found 
make[4]: *** [libgcc.a] Error 127 
make[4]: Leaving directory `/cygdrive/c/cygwin-gcc/build/ppc_gcc/gcc' 
make[3]: *** [stmp-multilib] Error 2 
make[3]: Leaving directory `/cygdrive/c/cygwin-gcc/build/ppc_gcc/gcc' 
make[2]: *** [all-gcc] Error 2 
make[2]: Leaving directory `/cygdrive/c/cygwin-gcc/build/ppc_gcc' 
make[1]: *** [all] Error 2 

 To fix this problem, just do:
$ cd /cygdrive/c/cygwin-gcc/local/bin 
$ cp xar.exe powerpc-ibm-eabi-ar.exe 
 and rerun "make ; make install" in `/cygdrive/c/cygwin-gcc/build/ppc_gcc/gcc'

 Extract of Makefile used to rebuild everything:
-------------------------------
FTPMIRROR := http://www.mirrorservice.org/sites/
GCC_VERSION := 4.1.1
BINUTILS_VERSION := 2.17
HOME = /cygdrive/c/cygwin-gcc
PATH := $(HOME)/local/bin/:/usr/local/bin:/usr/bin:/bin

src:
        mkdir src

build:
        mkdir build

local:
        mkdir local

lib:
        mkdir lib

target:
        mkdir target

src/gcc-core-$(GCC_VERSION).tar.bz2:
        wget --directory-prefix=src
$(FTPMIRROR)/sources.redhat.com/pub/gcc/releases/gcc-$(GCC_VERSION)/gcc-core-$(GCC_VERSION).tar.bz2

src/binutils-$(BINUTILS_VERSION).tar.bz2:
        wget --directory-prefix=src
$(FTPMIRROR)/sources.redhat.com/pub/binutils/releases/binutils-$(BINUTILS_VERSION).tar.bz2

src/gcc-g++-$(GCC_VERSION).tar.bz2:
        wget --directory-prefix=src
$(FTPMIRROR)/sources.redhat.com/pub/gcc/releases/gcc-$(GCC_VERSION)/gcc-g++-$(GCC_VERSION).tar.bz2

toolchain-src: src build src/gcc-core-$(GCC_VERSION).tar.bz2
src/gcc-g++-$(GCC_VERSION).tar.bz2 src/binutils-$(BINUTILS_VERSION).tar.bz2
        rm -rf build/*
        cd build && tar -xjf ../src/binutils-$(BINUTILS_VERSION).tar.bz2
        cd build && tar -xjf ../src/gcc-core-$(GCC_VERSION).tar.bz2
        cd build && tar -xjf ../src/gcc-g++-$(GCC_VERSION).tar.bz2

# PATH has to contains $(HOME)/local/bin/ before anything else here
# Add in /etc/profile the lines (after cd "$HOME") :
#    export HOME=/cygdrive/c/cygwin-gcc
#    export PATH=~/local/bin/:/usr/local/bin:/usr/bin:/bin
#    export INFOPATH=~/local/info:/usr/local/info:/usr/info
#    export MANPATH=~/local/man:/usr/local/man:/usr/man

native-toolchain: local
        [ -d build ] || $(MAKE) toolchain-src
        cd build && rm -rf native_binutils native_gcc && mkdir native_binutils
native_gcc
        cd build/native_binutils && ../binutils-$(BINUTILS_VERSION)/configure
--prefix=$(HOME)/local
        cd build/native_binutils && make && make install
        cd build/native_gcc && ../gcc-$(GCC_VERSION)/configure
--prefix=$(HOME)/local
        cd build/native_gcc && make bootstrap
        # - cd build/native_gcc && make -k check > check.log 2>&1
        cd build/native_gcc && make install

# That will fail if --prefix=... is not in the $PATH.
ppc-toolchain:
        [ -x local/bin/gcc ] || $(MAKE) native-toolchain
        cd build && rm -rf ppc_binutils ppc_gcc && mkdir ppc_binutils ppc_gcc
        cd build/ppc_binutils && ../binutils-$(BINUTILS_VERSION)/configure
--prefix=$(HOME)/local --program-prefix=x --target=powerpc-ibm-eabi
        cd build/ppc_binutils && make && make install
        # rm -rf build/ppc_gcc && mkdir build/ppc_gcc
        cd build/ppc_gcc && ../gcc-$(GCC_VERSION)/configure
--prefix=$(HOME)/local --program-prefix=x --target=powerpc-ibm-eabi \
                --with-cpu=440 --with-newlib --enable-languages=c
        cd build/ppc_gcc && make && make install
-------------------------------


-- 
           Summary: one reference to powerpc-ibm-eabi-ar.exe when only
                    xar.exe installed
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: powerpc-ibm-eabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770

[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-08-18 11:47 -------
powerpc-ibm-eabi-ar.exe should have been installed by binutils unless you are
doing a combined tree but since you are using a program prefix the problem is
that GCC does not take that into account for the ar, I think.
Can you give the output of the orginal configure for gcc?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |bootstrap


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770

[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[etienne_lorrain at yahoo dot fr]

------- Comment #2 from etienne_lorrain at yahoo dot fr  2006-08-18 12:25 -------
  I change --target=powerpc-ibm-eabi to --target=powerpc-eabi and
 --enable-languages=c to --enable-languages=c,c++ but the configure
 should be the same, I do not know what means "pre-installed"...

# rm -rf build/ppc_gcc && mkdir build/ppc_gcc
cd build/ppc_gcc && ../gcc-4.1.1/configure
--prefix=/cygdrive/c/cygwin-gcc/local
 --program-prefix=x --target=powerpc-eabi \
                --with-cpu=440 --with-newlib --enable-languages=c,c++
creating cache ./config.cache
checking host system type... i686-pc-cygwin
checking target system type... powerpc-unknown-eabi
checking build system type... i686-pc-cygwin
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for gnatbind... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1
$$f
2
checking for correct version of gmp.h... no
*** This configuration is not supported in the following subdirectories:
     target-libmudflap
    (Any other directories should still work fine.)
checking for bison... bison -y
checking for bison... bison
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... expect
checking for runtest... no
checking for i686-pc-cygwin-ar... no
checking for ar... ar
checking for i686-pc-cygwin-as... no
checking for as... as
checking for i686-pc-cygwin-dlltool... no
checking for dlltool... dlltool
checking for i686-pc-cygwin-ld...
/cygdrive/c/cygwin-gcc/local/lib/gcc/i686-pc-c
ygwin/4.1.1/../../../../i686-pc-cygwin/bin/ld.exe
checking for i686-pc-cygwin-lipo... no
checking for lipo... no
checking for i686-pc-cygwin-nm... no
checking for nm... nm
checking for i686-pc-cygwin-ranlib... no
checking for ranlib... ranlib
checking for i686-pc-cygwin-strip... no
checking for strip... strip
checking for i686-pc-cygwin-windres... no
checking for windres... windres
checking for i686-pc-cygwin-objcopy... no
checking for objcopy... objcopy
checking for i686-pc-cygwin-objdump... no
checking for objdump... objdump
checking for powerpc-eabi-ar... no
checking for powerpc-eabi-as... no
checking for powerpc-eabi-cc... no
checking for powerpc-eabi-gcc... no
checking for powerpc-eabi-c++... no
checking for powerpc-eabi-g++... no
checking for powerpc-eabi-cxx... no
checking for powerpc-eabi-gxx... no
checking for powerpc-eabi-dlltool... no
checking for powerpc-eabi-gcc... no
checking for powerpc-eabi-gcj... no
checking for powerpc-eabi-gfortran... no
checking for powerpc-eabi-ld... no
checking for powerpc-eabi-lipo... no
checking for powerpc-eabi-nm... no
checking for powerpc-eabi-objdump... no
checking for powerpc-eabi-ranlib... no
checking for powerpc-eabi-strip... no
checking for powerpc-eabi-windres... no
checking where to find the target ar... pre-installed
checking where to find the target as... pre-installed
checking where to find the target cc... just compiled
checking where to find the target c++... just compiled
checking where to find the target c++ for libstdc++... just compiled
checking where to find the target dlltool... pre-installed
checking where to find the target gcc... just compiled
checking where to find the target gcj... pre-installed
checking where to find the target gfortran... pre-installed
checking where to find the target ld... pre-installed
checking where to find the target lipo... pre-installed
checking where to find the target nm... pre-installed
checking where to find the target objdump... pre-installed
checking where to find the target ranlib... pre-installed
checking where to find the target strip... pre-installed
checking where to find the target windres... pre-installed
checking whether to enable maintainer-specific portions of Makefiles... no
checking if symbolic links between directories work... yes
updating cache ./config.cache
creating ./config.status
creating Makefile


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770

[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[bonzini at gnu dot org]

------- Comment #3 from bonzini at gnu dot org  2006-08-18 13:18 -------
If I remember/understand correctly, this "happened to work" in older GCC
releases (that is, the program prefix was added automatically if no other
target tool was found), except that after the installation GCC would forget
that the assembler is "xas" and not "powerpc-ibm-eabi-as".

The problem is that binutils will install itself into
$(HOME)/local/powerpc-ibm-eabi/bin/xar, not
$(HOME)/local/powerpc-ibm-eabi/bin/ar.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-08-18 13:18:40
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770

[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[bonzini at gnu dot org]

------- Comment #4 from bonzini at gnu dot org  2006-08-18 13:28 -------
No, I was misreading the binutils Makefile.

Etienne, can you confirm that you have $(HOME)/local/powerpc-ibm-eabi/bin/ar ? 
It is fixed in 4.2.0 if this is the case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770

[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[bonzini at gnu dot org]

------- Comment #5 from bonzini at gnu dot org  2006-08-18 13:34 -------
Anyway, the simplest solution for you is to build in a combined tree:

        cd build && rm -rf ppc_combined_src ppc_combined && \
          mkdir ppc_combined_src ppc_combined
        cd build/binutils-$(BINUTILS_VERSION) && find . -print | \
          cpio -pdlm ../ppc_combined_src
        cd build/gcc-$(GCC_VERSION) && find . -print | \
          cpio -pdlmu ../ppc_combined_src
        cd build/ppc_combined && ../ppc_combined_src/configure \
          --prefix=$(HOME)/local --program-prefix=x --target=powerpc-ibm-eabi
        cd build/ppc_combined && make && make install

It works for either native or cross, and for native it will test the binutils
by using them to compile themselves.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770

[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[etienne_lorrain at yahoo dot fr]

------- Comment #6 from etienne_lorrain at yahoo dot fr  2006-08-18 13:55 -------
 I do have $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe
 and I am using $(HOME)/local/bin/xar.exe for my stuff here, after install.
 To bootstrap, GCC may better use $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe
 but that will not be in the path, so GCC needs to call it with full path.

 I was thinking "combined tree" was not as good, mostly because I had to
 select which common part of the trees to keep - and well, I may have
 choosen the binutils ones (difficult to report a bug to binutils when you
 did not use their source to generate).
 Thanks for the trick about using cpio with or without the -u option (better
 than "rm -rf" in Makefile), and to show the order you use too.

 Etienne.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770

[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[paolo dot bonzini at lu dot unisi dot ch]

------- Comment #7 from paolo dot bonzini at lu dot unisi dot ch  2006-08-18 14:08 -------
Subject: Re:  one reference to powerpc-ibm-eabi-ar.exe
 when only xar.exe installed

etienne_lorrain at yahoo dot fr wrote:
> ------- Comment #6 from etienne_lorrain at yahoo dot fr  2006-08-18 13:55 -------
>  I do have $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe
>  and I am using $(HOME)/local/bin/xar.exe for my stuff here, after install.
>  To bootstrap, GCC may better use $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe
>  but that will not be in the path, so GCC needs to call it with full path.
>   
For 4.2.0, it will find it and use it:

if test x$host = x$build && test -f $srcdir/gcc/BASE-VER; then
    ...

gcc_cv_tool_dirs="$gcc_cv_tool_dirs$gcc_cv_tool_prefix/$target_noncanonical/bin$PATH_SEPARATOR"
else
    gcc_cv_tool_dirs=
fi
...
if test -z "$ac_cv_path_$1" ; then
  AC_PATH_PROG([$1], [$2], [], [$gcc_cv_tool_dirs])
fi

What 4.2.0 does is to use the same algorithm that the compiler will use 
to find the assembler/linker, and apply it for other tools such as ar.  
We decided that a configuration where this breaks is already broken too 
much.

For 4.1.x it was somewhat a mess.  What people were really doing "in the 
wild" was not yet clear, as it was by the time we finished cleaning up 
this stuff, so there were some unintended changes in the behavior.  But 
the combined tree will surely work.
>  I was thinking "combined tree" was not as good, mostly because I had to
>  select which common part of the trees to keep - and well, I may have
>  choosen the binutils ones.
>   
gcc should always win over binutils.  That's by design.  Changes to the 
toplevel are almost always driven by changes in gcc -- the binutils tree 
is mostly agnostic and just follows what gcc does.

Paolo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770

[Bug bootstrap/28770] [4.1 Regression] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[etienne_lorrain at yahoo dot fr]

------- Comment #8 from etienne_lorrain at yahoo dot fr  2006-08-18 15:04 -------
> For 4.2.0, it will find it and use it:

  Will that be in 4.1.2 (or is it in 4.1 prereleases) or only appear in 4.2 ?

> >  I was thinking "combined tree" was not as good, mostly because I had to
> >  select which common part of the trees to keep - and well, I may have
> >  choosen the binutils ones.
> >   
> gcc should always win over binutils.  That's by design.  Changes to the 
> toplevel are almost always driven by changes in gcc -- the binutils tree 
> is mostly agnostic and just follows what gcc does.

  The problem I have is that I am nearly always using the latest binutils
 because I did not get many regressions, but I sometimes regenerate with
 previous versions of compiler (GCC-3.4.5 or even try GCC-2.95.3) - maybe
 only for a quick test - and I better not get libiberty from them for
 binutils... but that is for the other project, with the other processor...

  Thanks,
  Etienne.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770

[Bug bootstrap/28770] [4.1 Regression] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[bonzini at gnu dot org]

------- Comment #9 from bonzini at gnu dot org  2006-08-18 15:36 -------
> Will that be in 4.1.2 (or is it in 4.1 prereleases) or only appear in 4.2 ?

No. :-(

> The problem I have is that I am nearly always using the latest binutils
> because I did not get many regressions, but I sometimes regenerate with
> previous versions of compiler (GCC-3.4.5 or even try GCC-2.95.3)

I see.  In fact those versions are even using Cygnus configure, so using them
in a combined tree is a mess.

There is no real solution.

A combined tree is ok for 4.2, with the latest binutils maybe 4.1 too.  But it
fails with older GCCs.

Backporting --with-build-time-tools to 4.1 would be a good idea, and then you
can just always configure with
--with-build-time-tools=$HOME/local/powerpc-ibm-eabi/bin (which would do no
harm for 4.2, which is where --with-build-time-tools works).  But it cannot be
done, for sure, for 3.x.

You can just stop using --program-prefix for the binutils.  Then you'll have
executables named powerpc-ibm-eabi-foo, which will work for GCC, and then
rename them to xfoo at the end of compilation (you can rename because GCC will
anyway use the executables in $HOME/local/powerpc-ibm-eabi/bin).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770

[Bug bootstrap/28770] [4.1 Regression] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.1.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770

[Bug bootstrap/28770] [4.1 Regression] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770

[Bug bootstrap/28770] [4.1 Regression] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.2                       |4.1.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770

[Bug bootstrap/28770] [4.1 Regression] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[jsm28 at gcc dot gnu dot org]

------- Comment #10 from jsm28 at gcc dot gnu dot org  2008-07-04 15:50 -------
Closing 4.1 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|4.1.1                       |4.1.1 4.1.3
         Resolution|                            |FIXED
   Target Milestone|4.1.3                       |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770