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.

As the other posters have said, there is some risk involved. The book recommends a completely new install of LFS. LFS took me a week to build and BLFS a further two weeks. I was not prepared to invest that length of time again for a new version of glibc. Other distros like Fedora, Gentoo, and Arch upgrade glibc regularly without any problems, so there must be a way.

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.

Attached Files

myversion.txt (679 Bytes, 138 views)

It gets quicker once you grow accustom to it and write some shortcut scripts. I can build one (lfs-base) from a Debian Live standard (no X11) cd in about 8 hours. Less if I skip all testing outside the toolchain and JIT/interpreters. Takes about 2 days or less to finish the rest, depending on what I am building it for.

Glibc is only updated once about every six months @ the upstream, IIRC. Also, distros have setups most LFS users won't bother with. Namely, ground-up auto-build servers that they can put something like a new glibc in and it will compile and test just about every package in their repository against it... and then email the developers a report. You may not know if you're in that .0x% incompatibility until some obscure and rarely used command pukes on you.

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.

That's great that you can do that.

Which of the 2 tasks take the shortest amount of time?
Building a script or performing a fresh install of LFS?

I was commenting that it gets faster the more times a person has built one. A week is how long it probably took me the first few times as well.

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.

Thanks for confirmation of it taking you about a week.

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?

Have you found that rebuilding is the only way around upgrading glibc?

Not what I meant. The "shortcut" scripts are things you develop as a natural consequence of being tired of typing everything by hand. What I meant overall is that: after you've built LFS several times it gets faster. You make less mistakes, you create scripts to help through the drudgery and you know intuitively what order things should be built in.

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.

1 members found this post helpful.

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.

1 members found this post helpful.

OK, I understand you now.
I'm all for making less mistakes.

Agreed:-

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.

1 members found this post helpful.

> 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).