Le 17/12/2013 16:11, John Burrell a écrit : >> My secret is that I use /tools toolchain for upgrading Glibc when >> necessarrry. Just point the PATH to /tools/bin before starting the >> upgrade and it should be done. Overwriting a file should get you the >> same result for many libraries which are used by the utility replacing >> the linker (cp, install, whatever). It needs to be a) removed first, >> then installed again b) overwritten, but not being in use at all. > Yes I could do it that way, but I was experimenting with a different approach > - storing the packages in archive files and then installing them in the > correct sequence. > > This all seems to work okay, except for ld2.18.so which creates the seg > fault. As I said in my original post, when I login to LFS after the update, > everything is fine. The linker has been updated and everything works as it > should. It's just that getting a seg fault is not a very satisfying result > and it would be nice to get around it. I'll try unlinking > ld-linux-x86-64.so.2, as Bryan suggested. > > jb. Do not know if Armin wants to comment, but when he says "from the same process", he means process in the kernel sense. If you do it with an interpreted language, for example: install glibc.so.xxx /path/to/some/place install ld.so.xxx /path/to/another/place The 2 installs are 2 different processes.
But normally, if you untar an archive with both files in it, it is a unique process, and it should work, I think. Regards Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
