How exactly a system might break by updating glibc?

Question

Suppose that I have a program that relies on a newer glibc version that is not available in the system via packages. And it gives:

version `GLIBC_2.xxx' not found

One solution is compiling the binary with glibc statically.

The other solution that is derailed by many people as "not safe" goes in putting newer libc.so.6 instead of the one shipped by operating system.

How exactly this second solution is not safe or a bad idea, provided that libc.so.6 includes prior ABI endpoints?

E.g. if I run strings /usr/lib/libc.so.6 | grep --perl-regexp "^GLIBC_" I can see a lot of those ABI versions like:

...
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
...

So if I'm overwriting with a newer libc.so.6 with additional glibc ABI versions inside it, how does it break older apps or leads system to breakage?

Or doesn't it...? :)

Answer 1

In general, binaries that were compiled for an older glibc version will run fine on a system with a newer glibc, as glibc is backward-compatible and handles automatically changes to its application binary interface (ABI). It achieves this wizardry by using symbol versioning, where basically to each symbol is attached a tag specifying its glibc version.

In case of semantics changes to function calls, glibc will include two versions, one for the old semantics and another for the new semantics, so each function is tagged with its version. The linker will consider both versions as two distinct functions.

This sophisticated mechanism is required since glibc is not one file but consists of many pieces (more than 200 shared libraries).

The backward-compatibility of glibc versions is under constant tracking. You may consult the ABI Laboratory report for API/ABI changes review for glibc. The report is generated by the abi-compliance-checker and abi-tracker tools.

For your question:

So if I'm overwriting with a newer libc.so.6 with additional glibc ABI versions inside it, how does it break older apps or leads system to breakage? Or doesn't it...?

Glibc compatibility is not fool-proof, but I believe that you will have to go way back to products compiled on quite old Linux versions to break it. I would also say that products may break not only because of glibc when run on versions of Linux different than where they were compiled.

So the best answer I can give is :
"It's not supposed to break anything, and there is an excellent chance that it won't".

For more information, see:

• The GNU C Library With Versioned Interface
• ABI compliance checker Notes
• ABI Policy and Guidelines

Answer 2

The direct answer to your question, is that if you use the newer (not necessarily supported) version. You have no guarantee that a function wasn't removed, or changed in such a way, that your other (older) applications will be able to cope with those changes. In fact they won't be able to cope with your new version, if your new version doesn't provide "shims" to support the so-called "legacy" functions that were removed, or incompatibly changed.

So, if your hoping for success in your endeavor, you'll need to examine the Changelog(s) following the "supported" Glibc version. To safely determine what changed. :)