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

[Paolo Carlini]

Hi,

and thanks for your analysis
> 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.
> 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?

Thanks again,
Paolo.