This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]