Re: Link tests after GCC_NO_EXECUTABLES

[Richard Sandiford <rsandifo@nildram.co.uk>]

Mark Mitchell <mark@codesourcery.com> writes:
>>> I really think that we ought to compare with what happens with MIPS or
>>> Power and figure out what's different.  Are you by any chance
>>> configuring a native compiler, rather than a cross?
>> 
>> No native compilers - I don't think the linux nommu memory manager would
>> be very happy about running gcc.  Running the testsuite is bad enough.
>
> Yeah, I didn't think so, but I was trying to think about what could be
> different.  I've CC'd Richard Sandiford, as I discussed some of the MIPS
> stuff with him at one point.

This may no longer be relevant given the rest of the thread, but for the
record: what you describe is indeed how things used to work before the
libtool upgrade.  (Although as Rask points out, linking never actually
failed for "int main () { return 0; }" without a -T option for MIPS;
it just gave a warning that __start was undefined and that the entry
point was being set to some built-in value.  I think both Dan and I
thought it should be an error instead, but that didn't fly...)

However, with the libtool upgrade, the shl_load test failed for MIPS
in the same way as it did for Bernd on Blackfin.  Rask got around this
by adding a "-T" option for the simulator board in top-level configure.
I still object to this approach for the reasons we discussed before,
but I didn't have time to come up with an alternative of my own,
so I didn't make a fuss.  It did at least get an unpatched libstdc++-v3
building again.

If Jie has a patch that gets us around the shl_load failure, I'd be glad
for us to go that route, and go back to not using the -T simulator options,
if that's possible.  Especially if we can do it before 4.3 is out, since
4.3 will then keep to the precedent set by earlier releases, and not set
a new precedent of its own.

Richard