Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell <mark at codesourcery dot com>]

Rask Ingemann Lambertsen wrote:

>> The issue isn't just Newlib; it's the "BSP" (crt0, system-call
>> implementations, etc.) that you might have in your individual system.
>> Some BSPs add considerable functionality beyond that provided by Newlib
>> itself, and we don't want libstdc++ to detect and rely on that.
> 
>    Ok, I got that. I suppose that means you don't actually have a way of
> making libstdc++ use such extra functionality?

Correct.

>    You wouldn't be using those libraries -- I wouldn't even expect people to
> actually wait for the libraries to build -- just check that 'configure
> --without-link-tests' runs to completion with no errors, then press ^C.

Oh, I understand now; that makes sense to me.

>>>    I have a feeling it would be more robust to simulate the link tests
>>> inside the autoconf/libtool macros themselves as opposed to explicitly
>>> avoiding them in each and every configure.{ac,in}. Supply an option
>>> --simulate-link-tests=file_with_results with the default being no and be
>>> happy.
>> We would still need to hard-code things.
> 
>    Yes. The difference being it wouldn't break the first time someone edits
> configure.ac. --simulate-link-tests=file would be similar to
> --cache-file=file, but anything not specified in 'file' would default to
> 'no' instead of being probed for. We would ship a file with the hard-coded
> answers. It would need no hacks, tricks or work-arounds in configure.ac, and
> it would deal with all the libraries, present, past and future, in one fell
> swoop.

That sounds plausible too.  For libstdc++, there's a fair amount of
target-specificity, so you'd presumably end up with multiple cache files
for various targets, but that sounds like it would work.  The tradeoff
is that you might end up adding checks for functions that are in fact
available in Newlib, but, because nobody added them to the cache file,
wouldn't be used.  The advantage to the current setup is that you get a
loud failure, and have to go actually work out the right answer.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713