/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found

[fedkad]

I am running "Lazarus 2.2.0 / FPC 3.2.2 / x86_64-linux-gtk2" on Ubuntu 21.10. The code compiled under this environment, when attempted to be run on a slightly older (but, still supported) version of Linux, for example Debian 10 will give an error like this:

./my_program: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./my_program)

How can I create Linux executable code that can be run on any version of GLIBC smaller than 2.34?

Note: "objdump -T my_program | grep -i glibc" output is something like this:

0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 wcrtomb
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 wcscoll
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.34  dlerror
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 setenv
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 setlocale
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 strcoll
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.34  dlopen
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 iconv_close
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 mbrlen
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.34  dlclose
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 mbrtowc
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.34  __libc_start_main
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.34  dlsym
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 iconv
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 iconv_open
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 nl_langinfo
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 towlower
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.34  dladdr
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 __errno_location
0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 towupper
0000000000000000  w   DF *UND*   0000000000000000  GLIBC_2.2.5 __cxa_finalize

[trev]

The obvious answer is to statically link the needed libraries rather than loading them dynamically. The most significant advantage of static linking is that the application can be certain that all its libraries are present and that they are the correct version. Static linking of libraries also allows the application to be contained in a single executable file, simplifying distribution and installation. Also with static linking, only those parts of the library that are directly and indirectly referenced by the target executable are included in the executable. With dynamic libraries, the entire library is loaded, as it is not known in advance which functions will be used by the application.

[PascalDragon]

How can I create Linux executable code that can be run on any version of GLIBC smaller than 2.34?

By compiling it on a system that has an older GLIBC. This is simply how things work on Linux or ELF files in general. See also Jonas Maebe's answer here.

[fedkad]

Thanks for the answers. I was expecting a compile and/or link option that will prevent the usage of GLIBC 2.34.

[Gustavo 'Gus' Carreno]

Hey Fedkad,

Thanks for the answers. I was expecting a compile and/or link option that will prevent the usage of GLIBC 2.34.

I've had the same issue since I'm also in Ubuntu 21.10 and I've noticed this quite a while ago.

I'm not sure the lower version `libc` is still installed in the system since I never bothered to actually go look, but if it still is, due to some relic binary that cannot link to 2.34, there could be a solution.

The solution I've thought about is to do with messing around `fpc.cfg` to have `libc` served from another folder.
I'm not quite sure if this is possible, since it would have to be passed to the lnker, but if possible, this would solve the problem.

In any case, this would be a case for the more experienced Free Pascal users on this forum to pitch in and give some suggestions of the if its possible OR how to go about it.

Cheers,
Gus

[dbannon]

Seems strange, I build my app on an U20.04 VM and it has libc6 2.31 and the resulting binary works fine on U16.04 and its a lot older 2.23 libc6.  Thats a far bigger jump than fedkad mentions.

Is there some more significant change taken place with 2.34 ?

Davo

[PascalDragon]

Is there some more significant change taken place with 2.34 ?

Yes, there is. They changed how the initialization works and thus an older libc with binaries compiled for a newer libc would lead to possibly hard to debug problems, because the initializers and finalizers of the binaries wouldn't be run.

The last change with a versioned symbol was with 2.1, though that probably wouldn't affect FPC and then 2.0 which would affect FPC (thus you can't use a FPC compiled binary compiled on a system with a glibc < 2.34 with a glibc older than 2.0).

[dbannon]

Hmm, I am not sure DP's explanation explains fedkad experience here though.

Debian Buster was updated to 2.28 recently (March 22) and that should work fine.

fedkad, is your Buster test system up to date ?

Davo

[fedkad]

fedkad, is your Buster test system up to date ?

No. I tested my executable at: https://distrotest.net/Debian

[dbannon]

I would recommend Virtual Box, only real downside is diskspace used by all the VMs you end up keeping.

And, maybe, a VM to build your application too ?  Thats how I work, I have a Bullseye VM where I build the SRC Debs for Debian and a U20.04 VM where I build my binary distributions, its setup to cross compile so I can make 64 and 32 bit Linux, (Debs and RPMs), Win32, RaspPi ....

Davo

[RDL]

@fedkad
Check my ticket on fpc gitlab
https://gitlab.com/freepascal.org/fpc/projects/-/issues/3

[MarkMLl]

Noting what everybody else has said, but I believe that the fundamental issue is that the linker resolves/follows symlinks so the actual filename in the executable is that of the actual library.

I don't believe that's fixable, it's quite simply the way that the linker and loader work on Linux (and possibly other unices).

I've definitely seen comparable issues, although I can't recall whether they specifically involved (g)libc. Also I can't say whether they apply to unices other than Linux, since I've rarely (if ever) had multiple versions of these running and in any event it's long been my policy to try to have FPC/Lazarus on representatives of all OS variants and versions.

A related problem I had a couple of years ago was due to an ALSA version change. I worked around that by putting Docker on my development system and setting up a container with the target OS such that I could ssh in and get a shell, after which I could run Lazarus and FPC in the normal way.

So I suggest that the first thing to do is to follow through the symlink chain on both systems. I'd be very happy to be told I was wide of the mark, and that there was a simpler fix :-)

Added: If it is a library naming issue, it might be possible to fix it using patchelf

http://manpages.ubuntu.com/manpages/bionic/man1/patchelf.1.html

I've not experimented with this, and I don't know what would happen if a symlink name was patched into the ELF header.

MarkMLl

[PascalDragon]

Noting what everybody else has said, but I believe that the fundamental issue is that the linker resolves/follows symlinks so the actual filename in the executable is that of the actual library.

It's not an issue with symlinks or the name of the library. The issue is that newer libcs have a versioned symbol and according to the ELF spec when a symbol that has a version attached is used then this needs to be referenced as such in the ELF binary so that the dynamic linker can then resolve this using the correct version of the symbol, this implicitly also means that if you try to run a binary that uses such a versioned symbol on a system where the corresponding library does not have this symbol with the suitable version (or none at all) then the binary simply won't load. It's as if you'd use a symbol that doesn't exist at all.

[abouchez]

Old Thread, but perhaps something was overseen.

The error states that dlopen/dlsym/dlclose are not available in the libc/'c'.
And they should not, because on Linux they are part of libdl/'dl' as stated by rtl/unix/dl.pp

My guess is there is something wrong somewhere in your code or its dependency, which define dlopen/dlsym/dlclose manuall as external 'c'.
Perhaps try to use the unit dl which defines things as expected.

[dbannon]

WOW, unbelievable !  This thread is many months old and we had a clash. abouchez, maybe my summary will help ?

OK, so its an old thread but still a problem.
I thought I'd summarize where we are at !

The issue as we know is that, on Linux system, binaries compiled on a system with glib6-2.34 or later will not work on systems using an earlier glibc6. These Ubuntu and Debian distros use the following glibc6 -

* U20.04  - 2.31   
* U21.04  - 2.33
* U21.10  - 2.34  (Impish)
* U22.04 -  2.35  (Jammy)

* D.Bullseye - 2.31
* D.Bookworm - 2.34

If you build your app on Ubuntu Jammy or Impish or on Debian Bookworm it will not run on a number of still currently supported systems. I am talking here about Ubuntu and Debian but obviously, same situation applies for all the other distributions !

To my surprise, a build on Jammy works fine on Impish so its a one off problem, not ongoing.

I, personally, will keep a Ubuntu 20.04 system going to use as a build machine for the packages I distribute directly, they will run everywhere and I can have a current FPC/Lazarus on them.

But I also distribute through an Ubuntu PPA, there you must use the FPC/Lazarus provided by the target release or build newer ones from a source package. Ubuntu, Bionic, U18.04 for example has Lazarus 1.8 and is still an officially supported release until April 2023.

I have in the past ported Lazarus 2.0.10 and FPC3.0.2 from Debian Backports to a PPA but really don't want to do that again, because Debian break these up into tiny little modules, its just too messy.

I assume the really good Lazarus and FPC debs distributed through SourceForge are built as binaries from the start, not as source packages ?  If source, they could be pushed to a PPA ...

Sigh ....

Anyway, there it is, if you build and distribute binaries to other Linux users, beware !

Davo