------- 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
