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

[Ian Lance Taylor]

Paolo Carlini <paolo.carlini@oracle.com> writes:

> I'm asking, because I'm not using cross-compilers much myself and we
> never discussed the issue before, as far as I can remember... The
> issue arises because I noticed that we have picked to be run only when
> native quite a few simple AC_TRY_COMPILE autoconf tests: it would be
> easy, I think, to run all those tests unconditionally, but then, in
> general, some features would become available to cross-compilers, with
> potential binary compatibility issues with old object code. A typical
> example would be [GLIBCXX_CHECK_INT64_T]...

I think that the current tests for cross-compilers in libstdc++
configury are somewhat broken, although I've never been sufficiently
motivated to straighten it out.  The configure script is testing for
whether libstdc++ is being built with a cross-compiler.  That is a
good thing to check when you are testing characteristics of the system
on which executables will be run.  It is not a good thing to check
when you are testing characteristics of the tools used to build the
executables.

A simple rule of thumb: a libstdc++ built using a cross-compiler to
i686-pc-linux-gnu should be binary compatible with a libstdc++ built
by a native i686-pc-linux-gnu.

For example, while I don't know offhand whether this affects binary
compatibility, it is incorrect to not test GCC_CHECK_TLS when being
built by a cross-compiler.  It's true that you can't get a complete
TLS test when being built by a cross-compiler, because you can't test
the kernel.  However, GCC_CHECK_TLS has a reasonable fallback for that
case: if the compiler and the binutils support TLS, it assumes that
TLS is fully supported.  GCC_CHECK_TLS should be invoked
unconditionally, not only if GLIBCXX_IS_NATIVE.  The same is true of
many other--though not necessarily all--tests currently controlled by
GLIBCXX_IS_NATIVE.

Ian