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

[c600g]

I stumbled onto this issue a couple weeks ago with a client that runs our shared library in an AWS Lambda Function environment (using an Amazon Linux 2 base image). Amazon Linux 2 uses a libc version without the pthreads and dl library integration changes, so trying to use our shared library built on the most recent stable Ubuntu release (or Fedora) results in an error.

Amazon is working on a new version of Amazon Linux (2022) with updated glibc support, but it does not seem ready yet and who knows when our client will decide to move over to that base image instead of AL2.

To address the problem, I am currently building a container based on Ubuntu 20.04 that will add the necessary dependencies to build FPC and Lazarus via fpcupdeluxe, and use distrobox to use that as my dedicated Lazarus build environment.

Alan

[MarkMLl]

libc without pthreads... yes, I've come across that combination on an x86_64 tablet when investigating FPC with Termux.

MarkMLl

[robert rozee]

my apologies for resurrecting an old thread, but here seems to be the most complete discussion of the matter... i just experienced the disastrous consequences of pushing out a software release compiled on a recent linux install (mint 21.1) that ended up linked against glibc 2.34. the outcome was a right mess, and i just spent several hours in a panic creating an old mint 19.3 VM to create a working executable that i could substitute.

here is the output i get from objdump -T progname | grep -i glibc piped through diff to show just the differences between 'bad' and 'good' executables:

Code: [Select]

                                  > (GLIBC_2.2.5) dlsym
(GLIBC_2.34) dlerror       | (GLIBC_2.2.5) dlclose
(GLIBC_2.34) dlopen               <
(GLIBC_2.34) dlclose              <
(GLIBC_2.34) __libc_start_main    | (GLIBC_2.2.5) dlerror
(GLIBC_2.34) dlsym                <
                                  > (GLIBC_2.2.5) dladdr
                                  > (GLIBC_2.2.5) dlopen
(GLIBC_2.34) dladdr               | (GLIBC_2.2.5) __libc_start_main
it seems the difference is not insurmountably large - just a few symbols - is there not surely some simple way to pick up the library file:  /lib/x86_64-linux-gnu/libc-2.27.so  and place it where the linker will find and make use of it? a whole VM just to fix 6 small differences seems quite excessive. i have read through the various threads on this and other forums, and it seems to me that there is a great deal of philosophical debate going on (for instance: https://gitlab.com/freepascal.org/fpc/projects/-/issues/3), with little pragmatic consideration.

the status quo: sending someone a program file that simply does not run, is a bit of a disaster. i feel we should be able to do better.


help, someone, please?


cheers,
rob   :-)

[MarkMLl]

the status quo: sending someone a program file that simply does not run, is a bit of a disaster. i feel we should be able to do better.

Compared with my comments to (and about) the developers about various build problems, I think you're being remarkably restrained :-)

I think your problem cries out for something like a Docker container, or an Appimage. Having seen various compatibility issues relating to Docker I think I'd lean towards the latter, but I don't know how to do it.

MarkMLl

[TRon]

... is there not surely some simple way to pick up the library file:  /lib/x86_64-linux-gnu/libc-2.27.so  and place it where the linker will find and make use of it?

There is not a proficiency present in the compiler / build system that I am aware of.

I would copy the required/wanted file to somewhere else and use the Fl option to point the compiler towards that directory. You could use a define in case you wish to support multiple glibc versions.

You/we (FPC) are not he only one facing this issue. It is easy to find online instructions on how to build an older version of glibc and what do do with it (when it comes to compiling/building).

the status quo: sending someone a program file that simply does not run, is a bit of a disaster. i feel we should be able to do better.

As said, FPC is not the only compiler having to deal with this issue (more accurate: the dev using the compiler)

[sketch]

You can have multiple versions of glibc installed on your server.

Code: [Select]

wget https://ftp.gnu.org/gnu/glibc/glibc-2.2.5.tar.gz
tar -xvzf glibc-2.2.5.tar.gz
cd glibc-2.2.5
mkdir build
cd build
../configure --prefix=~/opt/glibc-2.2.5 #or wherever you prefer
make -j8 #or however many procs you have
make install #add sudo if you don't have write privileges like to /usr/local in prefix

Then in C++ you want to use -Wl,--rpath=~/opt/glibc-2.2.5 and -Wl,--dynamic-linker=~/opt/glibc-2.2.5/ld-linux.so.2.27.  I'm not sure how you set those in FPC.

Or if you have patchelf installed, then you can run that with the path to ld-linux.so.2.27 and the rpath to where your new glibc is installed against the binary you've already created.

[marcov]

Then in C++ you want to use -Wl,--rpath=~/opt/glibc-2.2.5 and -Wl,--dynamic-linker=~/opt/glibc-2.2.5/ld-linux.so.2.27.  I'm not sure how you set those in FPC.

You can pass paths to the linker with -Xr and the dynamic linker with -FD.

[robert rozee]

i've tried all combinations of -Fl, -Xr and -FD plugged into the Custom Options field in the IDE, but the result when compiling is always much the same:

Code: [Select]

Warning: Only one source file supported, changing source file to compile from "~/pascal/GFXterm 2.1c/libc.so.6" into "project1.lpr"
i've got two copies of the 'good' library file (uplifted from mint 19.3), one named libc.so.6, the other named libc-2.27.so, sitting in my project folder. i've also tried copying these into the lib/x86_64-linux directory of my project. but no luck. it seems that persuading the IDE to allow picking up a library from somewhere other than what it considers to be the correct location is not so easy!

an idea that did occur: could one be tricky and create a 'fake' dynamic library containing just the 6 offending symbols, convincing lazarus that the symbols are not part of the operating system? this library does not need to be functional, just provide the symbols and links that go either nowhere or to empty routines. the fake library would serve purely to 'guide' the compiling/linking process, and would be deleted/removed/renamed once that is finished.

btw: i am far from a linux expert, but i do usually manage to muddle my way through!


cheers,
rob   :-)

[MarkMLl]

i've got two copies of the 'good' library file (uplifted from mint 19.3), one named libc.so.6, the other named libc-2.27.so, sitting in my project folder. i've also tried copying these into the lib/x86_64-linux directory of my project. but no luck. it seems that persuading the IDE to allow picking up a library from somewhere other than what it considers to be the correct location is not so easy!

Snippet for you: I'm not sure to what extent this is universal behaviour, but my experience on Linux is that any library symlinks are resolved at build- rather than run-time.

MarkMLl

[TRon]

i've tried all combinations of -Fl, -Xr and -FD plugged into the Custom Options field in the IDE, but the result when compiling is always much the same:

Code: [Select]

Warning: Only one source file supported, changing source file to compile from "~/pascal/GFXterm 2.1c/libc.so.6" into "project1.lpr"
i've got two copies of the 'good' library file (uplifted from mint 19.3), one named libc.so.6, the other named libc-2.27.so, sitting in my project folder. i've also tried copying these into the lib/x86_64-linux directory of my project. but no luck. it seems that persuading the IDE to allow picking up a library from somewhere other than what it considers to be the correct location is not so easy!

That is strange (or I am extremely lucky).

When I use FPC from the commandline and have another version of libc.so located in the directory from which I invoke FPC then FPC automatically/firstly picks up on that libc.so (according to gnu ld linker). I do have another issue but that is my fault as I also need to use/build the correct pthreads lib.

Have you tried to look at what adding the FPC option -k--trace produces for you ?

[Fred vS]

i've tried all combinations of -Fl, -Xr and -FD plugged into the Custom Options field in the IDE, but the result when compiling is always much the same:

Code: [Select]

Warning: Only one source file supported, changing source file to compile from "~/pascal/GFXterm 2.1c/libc.so.6" into "project1.lpr"
i've got two copies of the 'good' library file (uplifted from mint 19.3), one named libc.so.6, the other named libc-2.27.so, sitting in my project folder. i've also tried copying these into the lib/x86_64-linux directory of my project. but no luck. it seems that persuading the IDE to allow picking up a library from somewhere other than what it considers to be the correct location is not so easy!

an idea that did occur: could one be tricky and create a 'fake' dynamic library containing just the 6 offending symbols, convincing lazarus that the symbols are not part of the operating system? this library does not need to be functional, just provide the symbols and links that go either nowhere or to empty routines. the fake library would serve purely to 'guide' the compiling/linking process, and would be deleted/removed/renamed once that is finished.

btw: i am far from a linux expert, but i do usually manage to muddle my way through!


cheers,
rob   :-)

Hello.

Maybe not related but, fpc using "external", does not allow "extended" so extension ( libc.so.6 vs libc.so ).
You may try using a symlink libc.so with target libc.so.6.

[marcov]

IIRC you also needed -Xd to omit built-in paths. But it is all quite some time ago for me that I did it routinely, and the T_* files in the compiler might have changed since.

[MarkMLl]

Maybe not related but, fpc using "external", does not allow "extended" so extension ( libc.so.6 vs libc.so ).
You may try using a symlink libc.so with target libc.so.6.

Now that's an interesting one. If my understanding that symlinks are resolved early is correct, that means that a symlink such as libc.so in the project directory would be followed at build time, allowing a reference to an "alien" version of libc without jeopardising the stability of the remainder of the system.

MarkMLl

[TRon]

@MarkMLI: That is correct.

[dbannon]

I find it hard to believe that its not easier (and safer) to have a VM setup with a older OS such as U20.04 or Bullseye and do your 'release' builds there. I have such a VM, it has nothing except the things I know are needed to build and package. It's also good in that it will tell me if I have become dependent on a library I installed for another reason on my working machine that needs to be added to dependency list. Doing release builds on a dev system is not a great idea IMHO.

Davo