Hi Sam,

>> Without --with-gnu-ld, AC_ARG_WITH(gnu-ld) sets gnu_ld_flag to no.  The
>> later check to determine gnu_ld_flag from $gcc_cv_ld --version isn't
>> even run because it is guarded by test -z "$gnu_ld_flag".
>>
>> To avoid this, two things need to happen:
>>
>> * The ld --version check needs to be done in the ACTION_IF_NOT case of
>>   AC_ARG_WITH(gnu-ld), not afterwards.
>>
>> * For this to work, gcc_cv_ld needs to be set at this point.
>>
>> Therefore this patch does the first.  In order for the second to work,
>> AC_ARG_WITH(gnu-ld) is moved later when gcc_cv_ld has already been set.
>>
>> The same applies to gas_flag, too.
>>
>> Tested on x86_64-pc-linux-gnu and sparc64-pc-linux-gnu like so:
>
> Belated but LGTM.
>
> I'm happy to look at further patches for these as well
> (hopefully mostly in stage1; unfortunately the timing for the previous issue
> didn't interact well w/ FOSDEM timing).

thanks a lot.  I'm sure it's easy to miss some cases in my testing,
especially given that I've done only native tests/bootstraps so far.

When checking the uses of HAVE_GNU_AS/LD, it turned out that the vast
majority of them are in Solaris-specific code.  I think it would be way
clearer to explicitly check for Solaris as/ld directly, inverting those
guards to use HAVE_SOLARIS_AS/LD instead.

I've two patches for this almost ready, leaving the rest of the
HAVE_GNU_AS/LD cases untouched.  Once they've completed testing, we can
decide whether to apply them now or rather wait for stage 1.

Afterwards, only a handful of uses remain: 3 each for HAVE_GNU_AS and
HAVE_GNU_LD.  It should be possible to either eliminate those or convert
them to separate configure tests if need be.  That's certainly for stage
1 only.

> Thanks for handling all of this - it's pretty grotty and it took me a
> while to follow a bunch of it when I've had to look at it before.

Me too: it's been quite a maze which took me some time to untangle :-)

        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Reply via email to