This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Link tests after GCC_NO_EXECUTABLES
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