Re: gcc 3.3.4 cross build for mipsel mischooses the `as' to run

[Zack Weinberg <zack at codesourcery dot com>]

James E Wilson <wilson@specifixinc.com> writes:

> Zack Weinberg wrote:
>> This is a nice theory, but in practice I find that on any system where
>> there's a choice between (GNU as and/or ld) and (the system-provided
>> as and/or ld)
>
> I was talking about cross compilers, though I probably didn't make that 
> clear enough.  The rules are different for natives as you suggest.

Yes, sorry, I misunderstood.  Thanks for explaining.

[...]

> If MD_EXEC_PREFIX is a problem, we could perhaps fix it by moving it 
> after the tooldir_prefix code.  Thus we would look for GNU as before we 
> look for the native as.  However, this might break configure for people 
> who did not specify --with-gnu-as, as now they may be using it when they 
> did not intend to.
>
> Another possible solution would be disable use of MD_EXEC_PREFIX when 
> --with-gnu-as is specified.  We probably still want to add it to 
> startfile_prefixes, but we could avoid adding it to exec_prefixes.  That 
> might actually be a very good solution, as this means gcc will 
> automatically find the native as if you did not specify --with-gnu-as, 
> and will automatically find GNU as if you did specify --with-gnu-as 
> which is the behaviour we want.

These suggestions are counterintuitive to me.  I'm not sure I can
explain how, so let me instead try to explain what I would find to be
intuitive behavior.

First, as Mike Stump points out downthread, ideally I shouldn't ever
have to specify --with(out)-gnu-whatever; configure should select an
assembler and linker, then poke them and figure out whether or not
they are GNUish.  I'd find it useful to retain the options as
assertions: if I say --with-gnu-as, and the as that configure finds
isn't GNU as, it should error out.

Second, I think a sensible selection algorithm for native builds would
look something like this:

 1) Pathname explicitly specified by --with-as.
 2) ../gas/as-new, if a combined tree build (converted to (4) after
    installation)

 3) Pathname implicitly specified by --with-sysroot ($sysroot/$prefix/bin)
 4) Pathname implicitly specified by --prefix ($prefix/bin)

 5) $PATH at configure time.
 6) MD_EXEC_PREFIX.

For cross builds, 1,2 are the same, 4) becomes $prefix/$target/bin
instead of $prefix/bin, 5) should try only $target-as, and I'm not
sure about 3,6.

In both cases, if an assembler cannot be found, issue a warning but
don't fail to configure, because maybe I just want cc1.

No matter what assembler is selected, wire it into $prefix/$libsubdir;
then the driver can count on being able to find it next to cc1.
(Currently the driver falls back to path search or MD_EXEC_PREFIX,
which I think is wrong.)

I think the only case where this algorithm falls down is a
hypothetical system where MD_EXEC_PREFIX was set with the intention of
*overriding* the assembler/linker in the default path, because they
don't work.  However, I doubt such a system exists, and I could argue
that documenting "you need to adjust your PATH because /usr/bin/as is
broken" is an acceptable solution.

zw