Has anyone made any attempt to upgrade glibc?

[MikeNovember]

Hi,

One of the things that force to install a new version of a distribution is the compatibility problem: new applications use new libraries (example, OBS Studio 3.0 is no longer available for Mint 20.x / Focal, since it uses Qt6, not available on Mint 20.x / Focal).

Most of the libraries problems (ffmpeg 4.4.x, ffmpeg 5, ffmpeg 6, Qt 5.15, Qt 6...) can be solved by the use of PPAs or by compiling these libraries.

But, even after those libraries upgrades, one problem remains: glibc, and its library "libc.so.6".

On Mint 21.x, its version is 2.35:

Code: Select all

ldd --version
ldd (Ubuntu GLIBC 2.35-0ubuntu3.6) 2.35
Copyright © 2022 Free Software Foundation, Inc.
[...]

On Ubuntu Mantic or on incoming Noble it is 2.38.

Note that a given version of glibc offers an ascending compatibility and can be used by programs requiring a lower version:

Code: Select all

strings /usr/lib/x86_64-linux-gnu/libc.so.6|grep GLIBC_
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
GLIBC_2.18
GLIBC_2.22
GLIBC_2.23
GLIBC_2.24
GLIBC_2.25
GLIBC_2.26
GLIBC_2.27
GLIBC_2.28
GLIBC_2.29
GLIBC_2.30
GLIBC_2.31
GLIBC_2.32
GLIBC_2.33
GLIBC_2.34
GLIBC_2.35
GLIBC_PRIVATE

So, the idea would be to install glibc 2.38 to be able to use programs requiring it, without breaking the system.

A possibility would be:
- download glibc, https://ftp.gnu.org/gnu/glibc/glibc-2.38.tar.gz
- compile it, and install it in another place that the original glibc:

Code: Select all

# unpackage
tar -xzvf glibc-2.38.tar.gz
mkdir eag
mkdir /opt/glibc-2.38
cd eag
../configure --prefix=/opt/glibc-2.38
make
# If you are sure you compiled correctly, then install 
sudo make install

After that, "libc.so.6" 2.38 would be installed in "/opt/glibc2.38" while "libc.so.6" 2.35 would still be in "/usr/lib/x86_64-linux-gnu/".

We need now to have the system know that glibc 2.38 is installed.

In "etc/ld.so.conf.d" we create a "extralibs.conf" file; this file just contains the path to the directory where the new glibc is installed, "/opt/glibc2.38" (without quotes).

Then, sudo ldconfig updates the system with the path of the new library.

Theoretically, at next boot, "ldd --version" would say "2.38", programs requiring "libc.so.6" 2.38 would work, and programs requiring "libc.so.6" 2.35 would still work because "libc.so.6" 2.35 is still there, and/or because "libc.so.6" 2.38 offers an ascending compatibility.

All this is theoretical, and I might test it (after a complete system backup). My questions: does anybody have tested this or a similar approach to upgrade glibc? Does it seem reasonable, with some chances to work?

Regards,

MN

[Hoser Rob]

You have to realize that in Linux, all libraries are shared. There's nothing like Windows run side by side mode (or whatever it's called exactly). And glibc is one of the most commonly shared libraries, in all Linux distros.

In other words glibc isn't something you want to mess around with, that's a truly fantastic way to break the OS.

Is there a flatpak or other portable version of the app you want? That's what they're made for. The necessary dependencies are bundled in.

A number of users, especially ones with old hardware lacking RAM and storage, don't like flatpaks etc because of the extra overhead and non FOSS concerns about Snaps. I wouldn't install a snap unless I had to myself. But you can really have the best of both worlds with portable apps.

I like Debian Stable or Stable based distros. LMDE is an example of that But the software is even older than in Ubuntu based Mint. Usually I don't care because the new versions aren't really any different, but I can still get the newest version with flatpaks if need be.

[MikeNovember]

[...]
In other words glibc isn't something you want to mess around with, that's a truly fantastic way to break the OS.
[...]

Hi,

This is what most people say, and I have read it a lot of times.

However, people forget the ascending compatibility of glibc, confirmed by some (few) people on internet; and, in the installation I suggest, the original glibc stays unchanged, and the system has indexed both versions.

I don't see any a priori technical reason for failure.

I would like to see answers of people who tried, whatever they succeeded or not.

Of course, I am not in a hurrry and, with Virginia, I have installed all the applications I wanted, with the version I wanted.

It's more "intellectual curiosity" than anything else.

I might try it, in a distant future, after a full backup.

Regards,

MN

[Hoser Rob]

There are plenty of examples of users here on this forum and elsewhere who broke things like that, just search it yourself. Search engines are your friend.

[MurphCID]

Forgive my utter ignorance on this topic, but do not the libraries get an "upgrade" when we go from 21.0 to 21.1 to 21.2 etc? I seriously never thought about this before. I think it is a very valid question and I would be very interested in learning more from the experts.

[MikeNovember]

Hi,

The libraries may receive fixes, some libraries may be added, but glibc libraries keep the same version.
They come from Ubuntu, not from Linux Mint.
They change only when you change the major version (from Mint 20.x to 21.x), that means when you change the version of Ubuntu on which Linux Mint is based (from 20.04 to 22.04)
Linux Mint follows Ubuntu.

Regards,

MN

[MurphCID]

Thank you, I now understand a bit more.