Assessing the binutils/glibc TLS bug
fost at hotmail.com
Thu Dec 30 05:29:35 PST 2004
Matthew Burgess <matthew at linuxfromscratch.org> 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
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:
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 ;)
More information about the lfs-support