[RFC] Do we care about binary compatibility of code produced by cross-compilers?

[Paolo Carlini]

Hi Ian,
> Right now, when building a cross-compiler, libstdc++ simply assumes
> that _Unwind_GetIPInfo is available.  When building with a native
> compiler, GCC_CHECK_UNWIND_GETIPINFO does a link test to see whether
> it is there.
>
> I note that libjava calls both GCC_CHECK_TLS and
> GCC_CHECK_UNWIND_GETIPINFO unconditionally, even when building with a
> cross-compiler.
>   
Interesting.
> I assume your goal to have libstdc++ configury not perform any link
> tests.
>   
No link tests when non-native, I guess. We have some 
GCC_TRY_COMPILE_OR_LINK, which perform link tests when safe, when 
native, if I understand correctly the idea (not mine).

In general, when non-native, we have a GCC_NO_EXECUTABLES close to the 
beginning of configure.ac, and if it stays the games are over, right?
> In this specific case, because _Unwind_GetIPInfo is provided by the
> compiler support libraries when it is present, it might be possible to
> write a link test which works even if libc has not yet been built.
> The idea would be something like this:
>
>   hold_LDFLAGS="$LDFLAGS"
>   hold_LIBS="$LIBS"
>   LDFLAGS="$LDFLAGS -nostdlib"
>   LIBS="$LIBS -lgcc"
>   AC_LINK_IFELSE([AC_LANG_PROGRAM([[extern void Unwind_GetIPInfo();]],
>                                   [[Unwind_GetIPInfo();]])],
>                  [gcc_cv_getipinfo=yes],
>                  [gcc_cv_getipinfo=no])
>   LDFLAGS="$hold_LDFLAGS"
>   LIBS="$hold_LIBS"
>   
Thanks. Therefore you are suggesting changing the test itself, in 
/config along these ways, which would decouple it from libc, if I 
understand correctly. But it would remain a link-test, which would play 
bad with GCC_NO_EXECUTABLES in the libatsc++ configure.ac... What do you 
think?

Paolo.