5

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

Improve this question

2 Answers 2

Reset to default
7
+100

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:

Improve this answer
2
  • An excellent answer; I don't think my addendum is worth a separate filing. Ultimately this boils down to library versioning in general. If you have an API with three functions, {foo, bar, baz}, and want to release an update including a new one, the only safe way to do so is by appending it, {foo, bar, baz, diz}. If you add the new entry anywhere else, the "index" of each function at or beyond that point will change, and every program compiled against that library will fail to point at the correct functions. The same is true of in-memory data structures. Any non-append change will break.
    – GothAlice
    Commented Jun 21, 2019 at 2:04
  • With the proviso that this can be accounted for, e.g. by leaving "dead space", "padding" or gaps you can later fill. There are other techniques to protect against change, such as indirection like branch tables, e.g. PalmOS ROM, or thunks, popular with Microsoft.
    – GothAlice
    Commented Jun 21, 2019 at 2:47
0

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

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .