LinuxQuestions.org
Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Linux From Scratch
User Name
Password
Linux From Scratch This Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.

Notices


Reply
  Search this Thread
Old 02-14-2017, 08:45 PM   #1
sr_ls_boy
Member
 
Registered: Apr 2015
Posts: 68

Rep: Reputation: Disabled
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.

Last edited by sr_ls_boy; 02-14-2017 at 09:53 PM.
 
Old 02-14-2017, 10:42 PM   #2
Ztcoracat
LQ Guru
 
Registered: Dec 2011
Distribution: Slackware
Posts: 8,615
Blog Entries: 14

Rep: Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056
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-
 
Old 02-14-2017, 11:07 PM   #3
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 487

Rep: Reputation: 120Reputation: 120
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.
 
Old 02-15-2017, 11:17 AM   #4
plasmonics
Member
 
Registered: Jan 2009
Distribution: Fedora, Gentoo, LFS
Posts: 223

Rep: Reputation: 69
Quote:
Originally Posted by sr_ls_boy View Post
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.
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
File Type: txt myversion.txt (679 Bytes, 32 views)
 
Old 02-19-2017, 05:29 PM   #5
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 487

Rep: Reputation: 120Reputation: 120
Quote:
Originally Posted by plasmonics View Post
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.
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.

Quote:
Originally Posted by plasmonics
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.
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.
 
Old 02-20-2017, 11:41 AM   #6
Ztcoracat
LQ Guru
 
Registered: Dec 2011
Distribution: Slackware
Posts: 8,615
Blog Entries: 14

Rep: Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056
Quote:
I can build one (lfs-base) from a Debian Live standard (no X11) cd in about 8 hours.
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?
 
Old 02-20-2017, 01:52 PM   #7
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 487

Rep: Reputation: 120Reputation: 120
Quote:
Originally Posted by Ztcoracat View Post
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.
 
Old 02-20-2017, 02:37 PM   #8
spiky0011
Senior Member
 
Registered: Jan 2011
Location: PLANET-SPIKE
Distribution: /LFS/Centos6.3/Debian
Posts: 2,292
Blog Entries: 1

Rep: Reputation: 373Reputation: 373Reputation: 373Reputation: 373
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.
 
Old 02-20-2017, 09:26 PM   #9
Ztcoracat
LQ Guru
 
Registered: Dec 2011
Distribution: Slackware
Posts: 8,615
Blog Entries: 14

Rep: Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056
Quote:
Originally Posted by Luridis View Post
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.
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?
 
Old 02-20-2017, 09:27 PM   #10
Ztcoracat
LQ Guru
 
Registered: Dec 2011
Distribution: Slackware
Posts: 8,615
Blog Entries: 14

Rep: Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056
Quote:
Originally Posted by spiky0011 View Post
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.
Have you found that rebuilding is the only way around upgrading glibc?
 
Old 02-21-2017, 02:03 AM   #11
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 487

Rep: Reputation: 120Reputation: 120
Quote:
Originally Posted by Ztcoracat View 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?
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.
Old 02-21-2017, 12:07 PM   #12
spiky0011
Senior Member
 
Registered: Jan 2011
Location: PLANET-SPIKE
Distribution: /LFS/Centos6.3/Debian
Posts: 2,292
Blog Entries: 1

Rep: Reputation: 373Reputation: 373Reputation: 373Reputation: 373
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.
Old 02-21-2017, 03:17 PM   #13
Ztcoracat
LQ Guru
 
Registered: Dec 2011
Distribution: Slackware
Posts: 8,615
Blog Entries: 14

Rep: Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056Reputation: 1056
Quote:
Originally Posted by Luridis View Post
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.
OK, I understand you now.
I'm all for making less mistakes.

Quote:
Just having an already tailored kernel configuration will save several hours.
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:-
 
Old 02-22-2017, 03:03 PM   #14
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 487

Rep: Reputation: 120Reputation: 120
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.
Old 08-22-2017, 08:04 AM   #15
shevegen
Member
 
Registered: May 2004
Distribution: Slackware / GoboLinux / LFS / VoidLinux
Posts: 105

Rep: Reputation: 22
> 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).

Last edited by shevegen; 08-22-2017 at 08:05 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Upgrade redhat5 from glibc 2.5 to glibc 2.7 rupalim Linux - Software 6 11-14-2013 08:31 AM
upgrade glibc-2.3 to glibc-2.5 Tux-Slack Slackware 9 01-03-2011 06:40 AM
how to upgrade glibc-2.3 to glibc-2.4 safely on RHEL4? samengr Linux - Software 3 01-31-2009 01:30 PM
newb question on GNU glibc-2.3.1 upgrade to GNU glibc-2.3.2 clindy528 Slackware 1 11-10-2005 06:49 AM
upgrade glibc-2.2.4 to glibc-2.3.2 on redhat 7.2 Shuja Red Hat 0 07-28-2004 06:10 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Linux From Scratch

All times are GMT -5. The time now is 11:35 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration