How to upgrade glibc
LFS has a new release. I came for some pointers, asking to how
to upgrade to glibc 2.25. What would be the recommended way to upgrade this package without throwing away my 7.10 build. |
I'm not entirely sure how you would update glibc but I did do some reading online about it.
I found out that ....... Upgrading the standard library is risky, as some programs and libraries may depend on the current version. http://unix.stackexchange.com/questi...-upgrade-glibc http://linux-sxs.org/upgrading/glibc.html This looks like the best way to go about it. http://www.linuxfromscratch.org/lfs/...r06/glibc.html Hope that helps. Good luck-;) |
Unless you're talking about a security patch, which may or may not touch the ABI, there are differences that break backward compatibility. What you're asking about is actually more involved that upgrading the kernel, for which the headers used by libc stay forward compatible on the kernel side.
According to that chart, 2.24 to 2.25 is 99.70% backward compatible. But, what if that .3% is in something critical? Your best bet would be to keep the old one around in a versioned directory so you can use its linker if anything breaks until you can recompile the broken application. |
1 Attachment(s)
Quote:
I have upgraded glibc twice within LFS and so far no issues. I am not suggesting you follow any of this. FWIW here is what I did: Back up the LFS partition (for me, /dev/sda17) on a usb stick using Clonezilla. Using the LFS book, install the latest Linux API headers, e.g. 4.9.10. Compile and install the latest glibc. Recompile binutils, coreutils, dbus, util-linux, Bash, and Systemd. (Use the BLFS book for Systemd, since there is no longer any /tools directory for a completed system). Finally, recompile the kernel corresponding to the API headers you just installed, e.g. 4.9.10. Reboot. If you are using the proprietary nVidia graphics driver, you will have to reinstall it. If your graphics card is AMD/Radeon and you are using the Gallium driver built into the kernel, you do no have to install an extra driver. The BLFS infrastructure that was already in place works perfectly: Xorg, lxdm, Xfce4, various text editors, TexLive, music playback, browser, suspend/hibernate, etc. all work. I do not use KDE or Gnome, so I don't know if that could be a problem. Remember, if the process fails, you can restore the Clonezilla image. I am attaching version.sh in case it is relevant. |
Quote:
Quote:
I'm not trying to say you're doing it wrong or that you should not upgrade. Just warning you that "looks fine for the first week" might completely miss the intermittent off-by-1 write error that's slowly rendering your partitions unreadable. I figured out the hard way that regular backups are just as important for my LFS systems as my windows machine. |
Quote:
Which of the 2 tasks take the shortest amount of time? Building a script or performing a fresh install of LFS? |
Quote:
As for your question, I don't follow the context. What kind of script? If one is primarily interested in the speed of updates, something like Arch will most likely be faster. Unless a person can drop what they're doing the instant and update comes out and begin working on it. The point is, LFS is almost always more work than a distro, save maybe for customization. That, I find simpler on LFS. |
I just had the same delemar with glib update, I just bite the bullet and rebuild 2days got completly rebuilt, my problem is I have 5 different lfs builds all different DT so quite a bit todo.
|
Quote:
The scripts I'm referring to are the ones you mentioned as 'short cut' scripts in your previous post. I wonder if that's why I wasn't able to understand how to build LFS because I did not create short cut scripts? |
Quote:
|
Quote:
I mean, hell... Just having an already tailored kernel configuration will save several hours. Even if it's a new kernel, I can at least skip the what's still in the kernel from the last version with make silentoldconfig. |
Yes for glib it is the best way. I dont use scripts but as Luridis mentions you get better at building LFS the more you do it, Most of the config files you created in previous build you can reuse, It,s 1 of those things that you just do every now and then.
|
Quote:
I'm all for making less mistakes. Quote:
Not there yet with a tailored kernel so for now I'll stick with a solid base config and modify it. And, your right, knowing what order things should be built in is the key. I think that's one of the reasons why people get compilation errors because the configuration wasn't right. Thanks Luridis:- |
Personally, the way I would go about trying to do this is to first make a distribution tarball of my existing glibc as a backup. Then I'd make a dist tarball of the new glibc. Next, boot from a livecd, chroot into my system and untar the new glibc tarball into the system. If everything isn't working right you can always go back and untar your original glibc into place via the same process.
|
> The book recommends a completely new install of LFS.
LFS is wrong here since it depends on your approach. If you use the GoboLinux approach or any similar AppDir variant then just recompile whatever needs to be recompiled. I also recommend to get a static version of busybox on your system prior to upgrade glibc, just so that you can more easily recover; and compile most of the core programs such as sed, awk, m4 etc... statically too, prior to updating glibc, if possible. (Slackware build also seems to have a glibc instruction... I have not yet had a look at it but you can peek inside to see how they update glibc in general). With an AppDir approach, you can e. g. have /Programs/Glibc/2.25 safely next to /Programs/Glibc/2.24. A chroot is also quite simple if you use it in combination with an AppDir approach. I myself use something similar, such as GNU stow, just that I use a set of ruby scripts instead. These days I usually start with a slackware base install since it gives me the least trouble, and batch-compile everything from scratch using these scripts. (I can not yet recommend these for others though, as there are various shortcomings... but one day these scripts should be usable very well). Glibc is problematic largely because most stuff depends on it including gcc. That is why having the old glibc at e. g. /Programs/Glibc/VERSION_HERE is so useful - if anything fails with the new glibc, you just switch a symlink via busybox and things should work just fine (be wary when running "ldconfig" though and check before that everything is ok). |
All times are GMT -5. The time now is 11:25 PM. |