Re: Link tests after GCC_NO_EXECUTABLES

[Benjamin Kosnik <bkoz at redhat dot com>]

> if there is a rule that
> libstdc++ configure shouldn't try to link anything, it doesn't appear
> to be well enforced. 

The rule is that libstdc++ shouldn't do link tests unless it knows it
is native. Not "libstdc++ configure shouldn't try to link anything."

This means that there is a huge bias to do compile-time tests if at
all possible, as then native/cross configury is unified.

From configure.ac...

# Enable all the variable C++ runtime options that doesn't require
linking. 
GLIBCXX_ENABLE_CSTDIO

...

# Checks for operating systems support that don't require linking.
GLIBCXX_CHECK_SYSTEM_ERROR

...

if $GLIBCXX_IS_NATIVE; then

  # We can do more elaborate tests that assume a working linker.
  CANADIAN=no
....

The intent here seems obvious to me: is this not clear? 

It's not especially well enforced, as you note. (And other runtimes
may not take as much care or notice about this at all.) In particular, 

>> AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
>> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF

is not something libstdc++ has much control over.... I see this as a
bug in AM_PROG_LIBTOOL or these other macros.

> In any case, I think this is something that ought to be decided as a
> global policy for GCC and its run-time libraries, not something that
> differs between ports.  In particular, if run-time libraries are
> allowed to depend on linking in their configure tests, that's
> something everyone should know.

And....

> Since the preferred bare-metal setup is that linking not
> work without -msim (or a -T option), we don't want configure tests
> that detect any properties that might depend on what happens when you
> link. We want to make sure that detected properties are a property
> only of the parts that a user isn't going to change.

Thanks for this Mark. Absolutely agreed.

It is insanity to have this differ on a machine by machine or port by
port basis!!!! 

-benjamin