On 8/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
In the FAQ it says: "Another rule of thumb is: don't upgrade the toolchain (gcc, glibc and binutils)" But in the introduction of BLFS is says: "For micro version updates, a simple reinstallation usually works"
The BLFS intro is more accurate. The reason for the info in the FAQ is that updating the toolchain can be disastrous if it goes wrong. It's mainly a guard against people ruining their systems and getting upset about it. Doing a micro version update is safe when done correctly.
I would like to have some advice on this. Should I do the upgrade? And if, are there any special steps necessary? (like I found in a mail: configure; make; init 1; make install; init 3)
That's pretty accurate, but it leaves out a crucial safeguard. First, change down to runlevel 1. Basically, you want to minimize the number of running programs linking to glibc (all of them). That recommendation comes from Ulrich Drepper himself. Now, patch/configure/make just like in the LFS book, but don't "make install" yet. If you run "make install" directly, it will remove crucial existing libraries before installing the new ones. While this may not cause a problem, it could be disastrous. Imagine having a system with no libc. You're not going to get too far. So, you want to install into a temporary location. make install_root=/some/temp/location install That will install all the files into /some/temp/location. This is how all the distros do it. How you transfer the files from there to / varies. Here's one suggestion that I use on my system. I upgraded from glibc-2.3.4 to glibc-2.3.6 a couple months ago. I haven't had an issue. I stole this from Greg Shafer's scripts, and David Rosal, who wrote the paco package manager, has dubbed it the "tar sandwich". As root: cd /some/temp/location tar -cf - . | tar -C / -xf - Basically, you're using tar to archive all the files to stdout, then changing directories to / and extracting them from stdin. Tar will keep the permissions and ownership of the files when run as root. For reasons that I can't explain fully, this is safer than "rm /lib/libc.so.x.y.z && install -m755 libc.so.x.y.z /lib" which is basically what the Makefile would do. Something about the inode of the original files not being deleted because programs in use are linked to them. I'm sure the cluebat will be pulled out for that gross explanation. Then, you may want to reboot so that all the running utilities will release their link to the old libc. Or you could restart all the programs. Or, you can just keep going because it's not a problem and I'm misinformed.
I have an LFS 5.1.1 and don't want to do a new one from scratch. Just out of interest: What happens if one does an glibc-upgrade in gentoo?
They all use package managers. For instance, RedHat uses RPM. It installs to a temp dir and then uses cpio to copy to /. I don't know how ebuild works, though. Good luck. I'd make sure to make a backup of the original glibc and make sure I had a LiveCD handy in case anything terrible happened. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
