Assessing the binutils/glibc TLS bug

Chris Lingard chris at
Thu Dec 30 08:16:39 PST 2004

Steve Crosby wrote:

> Matthew Burgess <matthew at> wrote in news:cr0tdo$d7t$5
> <snip>
>> 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.

Thanks for that explanation, was not aware of that second bug; it explains
a lot.

> 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
> out).
> 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
> machine.

Yes, but the strip was in the book; so many people might hit this bug.
Also, who knows what host systems people are going to use.
> Reportedly, using shared library builds of binutils and gcc in Chapter 5
> also works, because they don't reference the broken host libc.a

Yes, this works. Had to do it to upgrade to the latest unstable.

More information about the lfs-support mailing list