Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell <mark at codesourcery dot com>]

Rask Ingemann Lambertsen wrote:

>    Here's a detail I'm missing. If you configure --with-newlib (or get it
> implicitly) and then link with something else when using the toolchain, then
> the answers will be wrong, but I don't see how that's any worse than
> assuming a set of hard coded link test results.

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.

>    How about an explicit option --without-link-tests, --disable-link-tests
> or something like that? Most people don't test on bare-metal targets and
> won't notice if they break, but given an explicit option to turn off link
> tests, you could make it a requirement to test that configure works with
> link tests disabled before checking in changes to configure.{ac,in}.

That's a reasonable idea, but as Joseph said, for GNU/Linux (and other
"hosted" platforms, presumably), we've decided we do need to do links,
so on those platforms, --without-link-tests would probably result in
broken libraries.

>    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.  For example, we want libstdc++
to call functions that are in Newlib (but might not be in other C
libraries).  So, libstdc++ has to have some way of asking whether the
function is in the C library, whether by linking, having the answer
hard-coded, or doing some other kind of probe (running nm?).

Thanks,

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