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

[Ian Lance Taylor]

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

> As regards GCC_CHECK_TLS, at the moment I don't understand the test
> well enough to take an immediate action: in general I moved to
> unconditional testing (e.g., both native and crosses) either tests
> using only AC_TRY_COMPILE, or using GCC_TRY_COMPILE_OR_LINK, or
> linking only in non-default cases, controlled by a configure-time
> switch.
>
> I don't think GCC_CHECK_TLS belongs to one of those "straightforward"
> cases, or, in other terms, I cannot convince myself that it's safe to
> move it as-is. Can you further help with it?

I agree that GCC_CHECK_TLS is not an obviously straightforward case.
The problem is that GCC_CHECK_TLS checks for TLS support in four
different areas: compiler, assembler, libc, kernel.  When building
with a cross compiler, there is no way to check the support in the
kernel.  Also, the current test does not test for support in libc when
building with a cross-compiler, although that could be fixed if you
permit a link test.

Anyhow, in the case of building with a cross-compiler, you have to
decide what the default should be.  Whatever you pick for the default,
it can be overridden by the --enable-tls option on the command line.
So what is the best default?

Today, I believe the best default is to assume that TLS is supported.
It has been supported by both the Linux kernel and libc for many
years.  The only supported threading library when using glibc on
GNU/Linux is NPTL, and NTPL assumes TLS support.  For embedded systems
running GNU/Linux which do not support TLS, the test for support in
the compiler will show that even when building with a cross-compiler.

I do admit that for the case of somebody using a very old kernel or
libc, and building with a cross-compiler, they may produce a libstdc++
which does not work for them.  They can fix it by configuring with
--disable-tls.

Ian