Bug 108947 - TLS backward compatibility failure
TLS backward compatibility failure
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-11-03 11:53 EST by adam.huffman
Modified: 2007-04-18 12:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-11-20 12:52:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description adam.huffman 2003-11-03 11:53:40 EST
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):

How reproducible:

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

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 16:00:57 EST
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 12:52:50 EST
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.

Note You need to log in before you can comment on or make changes to this bug.