> 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
