selection or target tools

[Paolo Bonzini]

Gunther Nikl wrote:
> On Fri, Dec 23, 2005 at 08:36:21AM -0500, Daniel Jacobowitz wrote:
> 
>>On Fri, Dec 23, 2005 at 01:19:14PM +0100, Gunther Nikl wrote:
>>
>>>Sorry for being vague, its a cross-compiler (build == host). The build
>>>errors out for libgcc.a since gcc/xgcc uses the "wrong" assembler. The
>>>last successful build was at the beginning of decemeber.
>>
>>Wait wait wait wait wait.  This is a cross compiler.  Are we mistakenly
>>running $prefix/bin/$target-as, which is a bad version, or are we
>>really running $prefix/bin/as, a program named "as"?  If we're doing
>>that, let's fix that separately - it's a nasty bug!
> 
> 
> $prefix/bin/$target-as was invoked through the script "gcc/as" created
> by stamp-as. AFAICT, that rule uses AS_FOR_TARGET. I am only using
> $prefix for cross compilers, thus there is no naked tool in $prefix/bin.

No, it uses ORIGINAL_AS_FOR_TARGET, which is the same `as' that the 
configure script ran the tests on (the variable is called gcc_cv_as 
during the configuration).

This, in turn, is the first that is found among:

1) the default assembler (--with-as)

2) an in-tree assembler

3) AS_FOR_TARGET

4) if host == target, AS (obsolete, should be covered by case 3)

5) if build == host, an assembler in one of the directories that the 
compiler will look at

6) if build == target, an assembler in one of the target-dependent 
search paths indicated by MD_EXEC_PREFIX

7) whatever tool, appropriately prefixed if host != target, can be found 
in the user's path (probably obsolete, should be covered by case 3).

In your case, case 5 used to hit, while now case 3 hits.  It is strange 
that you have seen this only from the beginning of December, because I'd 
expect the behavior to have changed in June or at most in October, with 
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00237.html (by Dan).

My proposed default setting of --with-build-tools would not even work in 
the strangest cases, such as if one was expecting the compiler to use 
tools from /usr/lib/gcc (!), which is admittedly even more remote but 
could happen.  To do everything correctly, cases 4/7 should be removed 
and cases 5/6 could be moved to the toplevel to provide the default for 
--with-build-tools.  We have the infrastructure to implement this, 
except that I'd hate to duplicate the definitions of MD_EXEC_PREFIX into 
the toplevel even if there are only half a dozen.

In the meanwhile (i.e. for 4.1, and on HEAD until this gets implemented 
if ever) I'd stick with a default --with-build-tools value of 
$prefix/$target/bin.

Paolo