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

[Ian Lance Taylor <iant at google dot com>]

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

>> 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.
>>   
> Ok, but I'm not sure to understand which is the role of any other
> target here, besides GNU / Linux systems: currently we are running
> GCC_CHECK_TLS for *any* native target.

True.  I don't know enough about other operating systems to know when
or if they got full TLS support.


>> 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.
>>   
> Ok, again, but I'm quite a bit confused about the practical
> implications: are you suggesting that "we" (by the way, the test
> belongs to /config, isn't a libstdc++-only test) change the test
> itself, simplifying it? Or are you suggesting that libstdc++ does
> something much simpler as regards TLS? Or something else?

I'm suggesting that libstdc++ unconditionally call GCC_CHECK_TLS,
rather than only calling it when GLIBCXX_IS_NATIVE is true.

To avoid any concerns with other operating systems, if you want to
only call GCC_CHECK_TLS when GLIBCXX_IS_NATIVE is true or when the
libstdc++ host is a GNU/Linux system, that is fine with me.

Ian