Forum > Linux

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

(1/49) > >>

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:

--- Quote from: fedkad on March 28, 2022, 03:59:03 pm ---How can I create Linux executable code that can be run on any version of GLIBC smaller than 2.34?
--- End quote ---

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,


--- Quote from: fedkad on March 29, 2022, 10:31:33 am ---Thanks for the answers. I was expecting a compile and/or link option that will prevent the usage of GLIBC 2.34.

--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

Go to full version