"Robert R. Russell" <[EMAIL PROTECTED]> wrote
Why is stripping the host binaries the issue?
1. There was a bug in binutils 2.15.92.0.1 and earler that caused the strip command to drop TLS symbols from static libraries. This was fixed in 2.15.92.0.2
2. There was *also* a bug in binutils 2.15.02.0.1 and earlier that caused the ld command to *incorrectly* resolve symbols if, when the two libraries being compared, only one had TLS symbols - ld would assume the missing information was not relevant, and use the TLS symbols in the library that had them. This was considered *bad* and ld was altereed to refuse to link in such circumstances. This change was also made in 2.15.92.0.2
So, if you used a buggy strip, but *also* used a buggy ld - things would work fine. When LFS-SVN upgraded to 2.15.92.0.2, it was discovered that they had been using a buggy strip for some time, and now ld was refusing to link the broken libs.
There is no way to recover the broken symbols - the workarounds mentioned either don't use static libs, use the older, broken ld (which by chance produces the correct linking result in our case), or re-installing the broken library with the symbols intact.
What if binutils were just rebuilt using the same package, but leave the libraries unstripped?
LFS 6.0 suffers from this issue, as it uses the broken strip (and the broken ld). When using LFS6.0 as a host to build LFS-SVN, which has a fixed ld, it rightly complains and refuses to link.
I don't understand. LFS 6.0 uses 2.15.92.0.2. Is there a problem with LFS 6.0 or not?
-- Bruce
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
