On Sun, May 21, 2006 at 05:35:27PM +0200, Aurelien Jarno wrote:
Because libstdc6++ is now provided by gcc-4.1, which need TLS support.
Without it you get when trying to run a C++ program:
libstdc++.so.6: cannot handle TLS data
Please see bug #361904 and all the merged ones for more information.
I don't see everything that's going on, but this makes no sense.
--with-tls is "support loading TLS data". --with-__thread is "use TLS
data internally".
The error message in question is guarded by USE_TLS. USE_TLS is
defined for ld.so if:
#if defined HAVE_TLS_SUPPORT \
&& (defined FLOATING_STACKS || !defined IS_IN_libpthread)
/* Signal that TLS support is available. */
# define USE_TLS 1
i.e. by --with-tls.
How is an ld.so built using --with-tls generating the error message?
That's a more serious, and I suspect different, problem. If it were
really the case, then /lib/ld-linux.so.2 would not have been able to
load the NPTL libraries and a lot more than libstdc++ would have broken!
Either turning on --with-__thread is just hiding the bug, or else I
don't understand the problem.
From #360776, it looks like it has to do with dynamically loading
libstdc++, which is a more complicated case. From the example, I
would guess that LD_ASSUME_KERNEL=2.4.1 perl -MAptPkg would reproduce
it.
Sure enough, with 2.3.6-6:
drow@nevyn:~/oldlibc% LD_ASSUME_KERNEL=2.4.1 ./lib/ld-2.3.6.so
--library-path ./lib:./usr/lib /usr/bin/perl -MAptPkg
Can't load '/usr/lib/perl5/auto/AptPkg/AptPkg.so' for module AptPkg:
libstdc++.so.6: cannot handle TLS data at
/usr/lib/perl/5.8/DynaLoader.pm line 225.
at - line 0
Compilation failed in require.
BEGIN failed--compilation aborted.
With 2.3.6-7:
drow@nevyn:~/oldlibc% LD_ASSUME_KERNEL=2.4.1 ./lib/ld-2.3.6.so
--library-path ./lib:./usr/lib /usr/bin/perl -MAptPkg
[no error]
So the change to use --with-__thread in 2.3.6-8 was not necessary to
fix the libstdc++ problem; why was it made, and can we revert it?