From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16308 invoked by alias); 18 Aug 2006 14:09:08 -0000 Received: (qmail 14849 invoked by alias); 18 Aug 2006 14:08:39 -0000 Date: Fri, 18 Aug 2006 14:09:00 -0000 Message-ID: <20060818140839.14848.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "paolo dot bonzini at lu dot unisi dot ch" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-08/txt/msg01448.txt.bz2 List-Id: ------- 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