Bug 108947

Summary: TLS backward compatibility failure
Product: [Retired] Red Hat Linux Reporter: adam.huffman
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 9CC: drepper, fweimer
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-11-20 17:52:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description adam.huffman 2003-11-03 16:53:40 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7

Description of problem:
In order to get support for the Broadcom 5705 ethernet card in a
laptop I have compiled kernel 2.4.23-pre9.

When I try to run a particular application I get the following error:

cannot set up thread-local storage: kernel too old for thread-local
storage support

and the application does not start.

This happens even if I add the 'nosysinfo' parameter to the kernel
command line.

The following error also occurs (it occurs when using a Red Hat kernel
too - it doesn't seem to affect the running of the application):

Incorrectly built binary which accesses errno, h_errno or _res
directly. Needs to be fixed.

Version-Release number of selected component (if applicable):
glibc-2.3.2-27.9

How reproducible:
Always

Steps to Reproduce:
1. Boot system with self-compiled kernel
2. Try to run application
3.
    

Actual Results:  Application fails to start, with error on command line.

Expected Results:  The application should have started normally.

Additional info:

Comment 1 Ulrich Drepper 2003-11-04 21:00:57 UTC
And what is your problem?

In the one case you have code which assumes features not present in
old kernels.  You should be glad that you get told about this early
and not when the application has already done some damage.

In the second case, using the variables, the application is compiled
incorrectly.  It happened to work in the past (even though
incorrectly), is patched up for now, but will probably fail in future.
 Again, the application is at fault.

And next time use something better than "Try to run application". 
Every application which can reasonably expect to work with a custom 
kernel does work.

Unless you provide concrete evidence that any of the applications you
have problems with is not using anything special I'll close this bug.

Comment 2 Ulrich Drepper 2003-11-20 17:52:50 UTC
Got no reply.

Again, the TLS glibc version requires the syscall to be available. 
There are alternative glibc version (in /lib/i686 and /lib) which can
be used by setting LD_ASSUME_KERNEL (see the release notes).  If a
program uses __thread or has a TLS segment for other reasons it needs
the TLS enabled version, unconditionally.  Run

  readelf -l BINARY | fgrep TLS

If this produces output, the application uses TLS.  This also must be
tested for all the DSOs which

  ldd BINARY

shows are used.

If you continue to think this is a bug reopen and provide exact
details about the program you are trying to use.