Bruce Dubbs wrote:
Jeremy Utley wrote:
Because the problem is actually if libc.a has been stripped with buggy binutils, removing the TLS information from the library. The only resolution would be to completely recompile Glibc.
I see. It's glibc that get corrupted. Would it be possible to download an unstripped LFS 6.0 version of libc.a and continue?
I don't see why not, but IMHO, it's far easier to just build the Pass1's dynamic instead of static - it sidesteps libc.a completely (uses libc.so instead), and definately works - I've used that process myself when building from jhuntwork's LFS 6 cd, which exhibits this problem. This is also the solution we recommend to people on IRC who encounter this problem. The end result, as far as I can tell, is exactly the same, since the dynamic pass 1's linked against the host's glibc are overwritten by the dynamic pass 2's linked against our new glibc.
-J-
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
