LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 07-31-2014, 08:23 AM   #1
nycbrit
LQ Newbie
 
Registered: Nov 2013
Posts: 14

Rep: Reputation: Disabled
Why is it not recommended to upgrade glibc?


Why is it not recommended that you upgrade glibc on a linux system?

Glibc is a strongly versioned library, so anything built against the old glibc should continue to work with the new glibc. Yet when you google for it there are many reports of problems & warnings of potential issues. If the binaries were built for an older glibc it should just work.
Redhat upgrades the kernel but not glibc. What am I missing?

Also, if a broken glibc is the only issue, why not put a newer one in a different directory and use LD_LIBRARY_PATH?
 
Old 07-31-2014, 08:56 AM   #2
pan64
LQ Guru
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 9,917

Rep: Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921
glibc is more or less the soul of the system. (almost) every app uses it. You can try to upgrade/downgrade an app and will not work if incompatible with the current glibc. but replacing glibc (using a broken one) means an unusable system.
 
Old 07-31-2014, 10:19 AM   #3
nycbrit
LQ Newbie
 
Registered: Nov 2013
Posts: 14

Original Poster
Rep: Reputation: Disabled
I'm ignoring downgrades of glibc here, that's surely going to break as existing apps will then be ABI incompatible with it.

Assuming you upgrade glibc :
If you upgrade an app and it requires a newer glibc, then why not upgrade glibc?
If you downgrade an app, it will require an older glibc, thus your newer glibc is still compatible.

Why is glibc different from other core libraries like openssl? That library gets upgraded by distros.

One issue I can think of is if you are building packages and distributing them. In that situation, you want the oldest glibc in order for your binary to be compatible with most linux systems.
 
Old 07-31-2014, 12:22 PM   #4
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,714

Rep: Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280
glibc is rather tightly tied to a kernel. Data structures, include files, system calls, and SOME interfaces are tied to a specific kernel line.

If you REBUILD glibc yourself, then MOST of such complications don't occur. The ones that remain are those where the older glibc doesn't support the functions, or glibc has some rather tight ties to the kernel data structures.

Normally, you can upgrade glibc (or even downgrade) - as long as major/minor kernel version stays the same (though like I said, sometimes there are interfaces that get dropped, or changes - this happens with ioctl and driver interfaces most often).
 
Old 08-03-2014, 04:39 PM   #5
nycbrit
LQ Newbie
 
Registered: Nov 2013
Posts: 14

Original Poster
Rep: Reputation: Disabled
Thanks for the replies! But it's still not clear to me. ioctl appears to be a function to pass-through commands to the kernel / drivers, so I would expect it may break if you upgrade the kernel or drivers, but not for a glibc upgrade - glibc could be made to be compatible. Do you have a specific example I could look at for (say) ioctl incompatibility when upgrading glibc?

Redhat & fedora build & distribute glibc once, then upgrade the kernel & kernel-headers regularly. In your reply, you said "Normally, you can upgrade glibc - as long as the major/minor kernel version stays the same", but did you mean the kernel version stays the same as the original or new version?

When building the glibc package, it asks for a minimum supported kernel version. This implies that it would support all kernel versions between the minimum and (at least) the kernel-headers version provided. Assuming the kernel-headers have the same set of patches (I think this is what you called "kernel line"). Is this correct?
 
Old 08-03-2014, 08:00 PM   #6
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,714

Rep: Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280
Quote:
Originally Posted by nycbrit View Post
Thanks for the replies! But it's still not clear to me. ioctl appears to be a function to pass-through commands to the kernel / drivers, so I would expect it may break if you upgrade the kernel or drivers, but not for a glibc upgrade - glibc could be made to be compatible. Do you have a specific example I could look at for (say) ioctl incompatibility when upgrading glibc?
Yes and no. Because glibc is built to a kernel, MOST are just passthrough to a specific driver, But the interface to the kernel does do some validation. The ones that would have the most difficulty are the ones embedded in other functions - such as ncurses. When substituting a shared glibc, if glibc is not compiled against the current kernel, some things just may not match. This IS less of a problem when the older glibc is compiled for the current kernel, but sometimes you will get compile errors (the kernel headers won't necessarily match the code - this is avoided for nearly all common uses, but sometimes...).
Quote:
Redhat & fedora build & distribute glibc once, then upgrade the kernel & kernel-headers regularly. In your reply, you said "Normally, you can upgrade glibc - as long as the major/minor kernel version stays the same", but did you mean the kernel version stays the same as the original or new version?
If the kernel version is something like Linux 2.2, and the current system is Linux 3.xx, then expect problems. Rebuilding the old glibc will cover most (if not all) of these mismatches.
Quote:

When building the glibc package, it asks for a minimum supported kernel version. This implies that it would support all kernel versions between the minimum and (at least) the kernel-headers version provided. Assuming the kernel-headers have the same set of patches (I think this is what you called "kernel line"). Is this correct?
It should. I haven't rebuilt glibc recently, but it should. The problem comes in when things like the compiler itself changes. Not all options of the older compilers will be available (it depends on "how old" the glibc being rebuilt is). It SHOULD compile. And if it gets compiled and linked (as in the libc.so) it should work. The kernel headers will be used to match the system calls, and whichever interfaces that are compatible.

There are some things left out - http://lwn.net/Articles/534682/

And some things do get added to libc, it is these differences that may cause a problem.
 
1 members found this post helpful.
Old 08-03-2014, 09:30 PM   #7
selfprogrammed
Member
 
Registered: Jan 2010
Location: Minnesota, USA
Distribution: Slackware 13.37, 14.2
Posts: 316

Rep: Reputation: 76
I have often wondered what the actual restrictions were.

I note the following, which I believe to be true.
1. A new version of GLIBC exists before the new kernel is compiled. There seems to be a
reason for this ordering and that it must be maintained.
2. Most programs have a single relationship to GLIBC. They allow the loader to link
to it to satisfy function calls. The loader actions adapt to a new GLIBC.
3. I expect GLIBC calls can appear in the kernel.
4. GLIBC uses many kernel calls to implement the GLIBC backend. Anything I/O related will obviously lead to a kernel call. This is entirely different than any other program relationship to a library and may be the actual source of many errors.
5. The kernel does not obey all normal compiling expectations. It may finagle some relationships and its relationship to GLIBC may be one of them. It what and where I would be interested in finding out.
 
Old 08-03-2014, 11:31 PM   #8
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,714

Rep: Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280Reputation: 1280
#3 isn't true. The kernel doesn't use glibc. There are a few functions that are similar. If you have the kernel source these are in <linux kiernel source base>/lib. Most notably are some of the string functions, sort, zlib functions, and kernel printf functions. These are NOT libc - because the kernel doesn't have the same programming context that libc does. Memory management is not available for instance.

In some cases functions have similar names just because the have a similar function - but they don't work the same way, and usually have less features.

Other functions there just don't exist in libc. The functions in the kernel lib tree are just to support the kernel.
 
Old 08-11-2014, 04:02 PM   #9
nycbrit
LQ Newbie
 
Registered: Nov 2013
Posts: 14

Original Poster
Rep: Reputation: Disabled
I also found this useful thread from the Redhat glibc team lead :

http://permalink.gmane.org/gmane.com...libc.user/2291

It reiterates & gives specifics on the issues raised here. One notable addition is LD_LIBRARY_PATH isn't sufficient to override the linux ld.so loader, so you have to either prefix the command with my-new-glibc/ld.so or use patchelf.
 
1 members found this post helpful.
Old 08-11-2014, 08:34 PM   #10
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 16,001

Rep: Reputation: 2219Reputation: 2219Reputation: 2219Reputation: 2219Reputation: 2219Reputation: 2219Reputation: 2219Reputation: 2219Reputation: 2219Reputation: 2219Reputation: 2219
Thanks for the update.
 
  


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 09:31 AM
Recommended Upgrade Frequency wschnaar Linux - Enterprise 4 02-21-2009 04:02 PM
how to upgrade glibc-2.3 to glibc-2.4 safely on RHEL4? samengr Linux - Software 3 01-31-2009 02:30 PM
dist-upgrade to Testing --NOT Recommended-- jlinkels Debian 30 11-29-2005 02:42 PM
upgrade glibc-2.2.4 to glibc-2.3.2 on redhat 7.2 Shuja Red Hat 0 07-28-2004 07:10 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 05:16 PM.

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