[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#368022: libc6: rational rose license manager fails to start since last glibc update



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?

-- 
Daniel Jacobowitz
CodeSourcery



Reply to: