Assessing the binutils/glibc TLS bug

Steve Crosby fost at
Thu Dec 30 05:29:35 PST 2004

Matthew Burgess <matthew at> wrote in news:cr0tdo$d7t$5


> 1) Which package failed to build (and was this in chapter 5 or 6)?

Chapter 5 binutils - actually the linker changes (make -C ld), not 
binutils itself

This is because the host binutils\glibc combination is used to build 
Chapter 5 binutils, but the new Chapter 5 binutils\host glibc are used 
for the linker changes.

> 2) What version of binutils does your host system have?
2.13.2 - yes, it's an old host ;)
glibc 2.3.2 as well (libraries and binaries all stripped)

> 3) What version of binutils did you install in chapter 5?
Tried the following: (worked) (failed) (failed)

You may be confused by the fact there are *two* bugs here. The original 
bug (very, very old and only recently noticed) is that "strip" removes 
TLS symbols incorrectly (apparently for static libs only - although thats 
a guess on my part).

The second bug is that versions of binutils prior to 94.0.1 did *not* 
check to see if the TLS version matched between conflicting symbols - 
that is if a symbol had no info, and a conflicting symbol had TLS info, 
the TLS info was *assumed* to be correct - this behaviour was changed in 
94.0.1 to return an error instead.

So, if you stripped libraries using a buggy version of strip on TLS 
enabled systems, then TLS symbol info was lost.

If you then attempted to build binutils using version 94.0.1 or higher, 
it would detect the missing TLS info and abort (version earlier than 
94.0.1 would assume TLS info and merrily continue - correctly as it turns 

If you rebuild libc.a on the host and don't strip it (or use a fixed 
strip command), the above versions of binutils all compile fine on my 

Reportedly, using shared library builds of binutils and gcc in Chapter 5 
also works, because they don't reference the broken host libc.a

hope that helps (and the above info is my interpretation, which may be 
offbase somewhat ;)

- --
Steve Crosby

More information about the lfs-support mailing list