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?

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.

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.

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

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?

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

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.

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

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.

Thanks for the update.