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

[TRon]

@robert rozee:

Assuming we can't use FPC itself for creating the library (? haven't tried either) I performed the following steps:

1. Create a fake libdl.so file using following libdl.c

Code: [Select]

void dlopen() { }
void dlsym() { }
void dladdr() { }
void dlclose() { }
void dlerror() { }
void __libc_start_main() { }

2. Build fake libdl.so file with

Code: [Select]

gcc -fPIC -shared -o libdl.so -Wl,--soname='libdl.so.2' libdl.c

3. Placed fake libdl.so to somewhere on my system, as an example /media/ramdisk/patches/robert/fakelibdl

4. Created a small threading example taken from the wiki (https://wiki.freepascal.org/Multithreaded_Application_Tutorial#Pure_FPC_example) naming it threadtest.pas

5. Compiled project with:

Code: [Select]

fpc -B -k--library-path="/media/ramdisk/patches/robert/fakelibdl" threadtest.pas

if you wish to know what is happening during linking stage you can use:

Code: [Select]

fpc -B -k--trace -k--library-path="/media/ramdisk/patches/robert/fakelibdl" threadtest.pas

So far, seems to work as intended. Note that above steps remove the requirement/need to have the fake libdl.so in your project directory. The option can be added to your lazarus project, to your fpc.cfg (f.e. possible by checking for a define to make it optional)  or to your fpc.sh script (I have already incorporated it to be able to compile with fpc -fake -B threadtest.pas)

[robert rozee]

TRon: excellent work. testing as widely as possible is the big thing at the moment, and threading is something that i was worried might not work!

[...] for Lazarus you are allowed before a build or compilation (but also after) you can invoke a custom exe or script to realize something [...]

can these be placed in the fpc.cfg file, so that the script or .exe is invoked for every project without needing to add it via the Lazarus IDE?

i'm thinking of one program (before) that is just a popup that asks "Do you want to use unversioned GLIBC symbols?" and writes the libdl.so file if the yes button is clicked, then another (after) that silently removes the libdl.so file and uses readelf to check that all symbols in the compiled binary are unversioned - if not, it pops up a warning message. i'm currently thinking that automatically adding symbols is a problem, as void name() { } doesn't work for everything. eg towlower and towupper. it may be sufficient to have a copy of libdl.c in a thread on here that people can add to as new symbols that need unversioning are found.


attached is a 5-page writeup on the current state of things. subject to suggestions and corrections - i'm not 100% sure on many things!

dbannon: would this form a suitable basis for a wiki page?

marcov: is this the sort of summary you were thinking of?


cheers,
rob   :-)

[funlw65]

...

attached is a 5-page writeup on the current state of things. subject to suggestions and corrections - i'm not 100% sure on many things!

dbannon: would this form a suitable basis for a wiki page?

marcov: is this the sort of summary you were thinking of?


cheers,
rob   :-)

I bet it is!

Thank you for the solution. All developers of commercial apps will be affected by this, and not only the Pascal programmers.

I wonder what unthinkable changes are expected in the Linux kernel if such restriction is required to force the future adoption of what is coming...

[dbannon]

dbannon: would this form a suitable basis for a wiki page?
....

Sure, its a serious work, might be a paper in it !

I think I would present, on the wiki page, the solution first, the supporting information can remain in the PDF, accessible from the forum post. Sadly, most users will want a simple solution that works. Few will read past that.

My guess is that the simple solution will encourage more people to test it, probably find problems so, will need refinement but it is a brilliant start. Once its stable, proven, we'll annoy the developers again !

First, I'll try and replicate the system just from your PDF, on a clean system. I am about to head off on a trip in a few days, might be a bit slow I am afraid. If I can make a start, someone else might "collaborate".

Nice work !

Davo

[funlw65]

dbannon: would this form a suitable basis for a wiki page?
....

...
I think I would present, on the wiki page, the solution first, the supporting information can remain in the PDF, accessible from the forum post. Sadly, most users will want a simple solution that works. Few will read past that.

My guess is that the simple solution will encourage more people to test it, probably find problems so, will need refinement but it is a brilliant start. Once its stable, proven, we'll annoy the developers again !
...

Davo

It wasn't hard to rapidly extract the right information and prepare the solution as described... All people interested in will get it right. Not this is the problem. The thing is, this post is quite "hidden", I would have not known about it if it weren't a person to signal this to me...

[TRon]

Thank you for the write up robert. It was a nice understandable read.

fwiw: I've given up (at least for now) on trying to build the library with FPC. It simply refuses to change the soname, which is one of the main parts of the issue. Can probably approached by using symlinks but the while idea was to make things easier and not complicate things (even) further.

can these be placed in the fpc.cfg file, so that the script or .exe is invoked for every project without needing to add it via the Lazarus IDE?

Sure, no problem.

you can simply add ...

Code: [Select]

-k--library-path="/path/where/your/fake/libdl/is/stored"
... to your fpc.cfg file

But 'every project' is a very strict (or broad, depending on your view) concept. I better explain that one 

People can use Lazarus to cross compile to other platforms. It is not very intuitive if that would introduce libfakedl especially not for those platforms it has no meaning (et all). Besides that, some (Linux) host's "do not suffer" from this particular issue because the OS (still) relies on using 'old' trusty libc.

So, making it optional in the fpc.cfg file by using a symbol would be much nicer, which could look something like:

Code: [Select]

#ifdef usefakelibdl
-k--library-path="/path/where/your/fake/libdl/is/stored"
#endif
which would then allow to compile with

Code: [Select]

  FPC -B -dusefakelibdl programname.pas
Or in Lazarus's terms, you can add a define to either your project settings or create special build mode that defines the symbol (by default). Depends a little on your preference.

To make it more generic (and explicit at the same time) it would perhaps even be better to add additional checks such as

Code: [Select]

#ifndef FPC_CROSSCOMPILING
#ifdef RELEASE
#ifdef LINUX
#ifdef CPUX64
#ifdef usefakelibdl
-k--library-path="/path/where/your/fake/libdls/are/stored/per/target/$FPCTARGET
#endif
#endif
#endif
#endif
#endif
but it depends a little for which exact situation(s) you want to make use of the fake libdl. I've gone overboard with the checks simply because I would opt using the fakelibdl only for this particular target (and only if you wan it to). Note a) the additional checks and b) the part where an extra directory ($FPCTARGET) is introduced which allows the fake dl library to be target dependent.

As an additional note to your post. Note that someone could opt (such as fpcUpDeluxe) for shipping the fake library so that user's do not have to compile it themselves and by using the custom path it can be stored somewhere neatly where it doesn't have to be a bother. Still risky since you would have to make darn sure the symbols declared in the fake library have to match otherwise it could lead to compiler (actually link) errors.

[DonAlfredo]

About fpcupdeluxe.

As there are two methods to circumvent the GLIBC versioning, I am still investigating what to do.
Implemented at the moment is the easy one.
I have added a linux-legacy cross-compile target. This target will download very olds libs. And link against these. It also sets FPC_USE_LIBC to force the legacy-rtl to use libc calls instead of direct sys-calls. I am testing this.
Method2 with the fake library is hard to do, and also more a hack than using old libs. But it works. Still looking into this.

And thanks for the nice read about this subject !!

[Thaddy]

Jus test for < 2.34

[TRon]

Jus test for < 2.34

Just to humor the idea. How do you suggest doing that when... let's say .. cross-compiling from x86_64 to arm ?

All possible solution mentions loading libc and use get_version_number (don't think adding an arm emulator would simplify things), or use the gnu compiler to detect the version using the libc sources (adding dependencies for gcc, gnu libc sources which also isn't considered very user friendly not to mention having to write some c-code).

So that leaves us pretty much empty handed (unless there is something that I overlooked). Yes, you could opt for doing so when compiling where host and target are the same architecture.

[robert rozee]

Jus test for < 2.34

[...]
All possible solution mentions loading libc and use get_version_number
[...]

and therein lies the problem - you need to load libc in order to get the version number, but you need to know the version number before you load libc!

i have come up with a solution that can work around this, but it is very very ugly. you have a compressed binary of your application, and a difference file (also compressed) that allows patching the (once uncompressed) binary from 2.2.5 compatible to 2.34 compatible. these are both bundled up into a simple console application (with no libc dependencies) that unpacks the original into /tmp and decompresses it, then decides which version you need and if required applies the patch before running the binary from /tmp. it actually works pretty well, is transparent to the user, but requires quite a bit of work to put together.


also Fred vS has now got a patched version of FPC that can generate GLIBC_2.2.5 versioned binaries without need for fake libraries or any other tricks:
https://github.com/fredvs/freepascal-ootb

it appears that there is something 'odd' in external that has thwarted efforts to simply specify the GLIBC version for symbols, i'm moving towards thinking it is a bug that creates an incompatibility with the way that GLIBC 2.34 and later structure the /lib/x86_64-linux-gnu directory. basically there is a libdl.so.2 placeholder library file in there, but FPC can not 'see' it. if renamed to libdl.so then all is well from the FPC perspective and introducing versioned symbols is easy.

looking at an old linux (Mint 19.3, GLIBC 2.27) it seems there may never have been a libdl.so file or symlink, which leaves me a little surprised that the linux related code in dl.pp ever worked as intended.

now one could just hack the /lib/x86_64-linux-gnu directory, but that is a rather impolite thing to do and may break things elsewhere in GLIBC.


cheers,
rob   :-)

[TRon]

and therein lies the problem - you need to load libc in order to get the version number, but you need to know the version number before you load libc!

Who would have thought chickens would produce eggs and vice verse 

i have come up with a solution that can work around this

tbh I haven't had the time to investigate further. In theory it should be possible to extract the information form the compiled lib but the main problem is figuring out how is it stored.

also Fred vS has now got a patched version of FPC that can generate GLIBC_2.2.5 versioned binaries without need for fake libraries or any other tricks:

Thank you for mentioning that. I had no idea fred was working on that. It should be possible to clean that up a little but note that I'm not that familiar with the compiler internals.

looking at an old linux (Mint 19.3, GLIBC 2.27) it seems there may never have been a libdl.so file or symlink, which leaves me a little surprised that the linux related code in dl.pp ever worked as intended.

Magic 

If you look a bit closer then you'll notice that the dl functions are part of glibc and as such the FPC unit links against libc (on/for certain targets) so that is probably what you have overlooked ?

[robert rozee]

If you look a bit closer then you'll notice that the dl functions are part of glibc and as such the FPC unit links against libc (on/for certain targets) so that is probably what you have overlooked ?

i take it you mean the line in dl.pp that reads:

Code: Pascal  [Select][+][-]

1. {$if defined(linux)}
2.     { if libc is not linked explicitly, FPC might chose the wrong startup code, as
3.       libdl depends on libc on linux, this does not hurt }
4.     {$linklib c}
5. {$endif}

i've found that the $linklib is ignored, no matter what i change it to.

similarly, changing the line:

Code: Pascal  [Select][+][-]

1.     LibDL = 'dl';

makes no difference. the sting is ignored no matter what it contains.

it is as if the parameters passed to external should be directing the linker, but are instead ignored. hence the need to provide the linker with external cues - like the fake libdl.so file dropped into the project directory. i've found that even if the fake libdl.so file contains no symbols, it still works to allow versioned symbols introduced to pp.dl to be picked up correctly. remove the empty fake libdl.so file, and the binary won't run against GLIBC 2.27.


cheers,
rob   :-)

[TRon]

@robert:
I am not quite sure what you are saying.

If you are looking for actual output of the linker then you explicitly should make use of the unit. f.e.

Code: Pascal  [Select][+][-]

1. program test;
2. uses
3.   dl;
4. begin
5.   writeln('hello');
6. end.
7.  

And when you compile

Code: [Select]

fpc -va -B -k--trace -k--verbose -k--stats test.paswhen f.e. you have changed the name of the library....you are in for a (output log) treat 

More disturbing is the output from my current system in use:

Code: [Select]

/usr/bin/ld: mode elf_x86_64
attempt to open /home/apps/fpc/3.2.2/units/x86_64-linux/rtl/si_prc.o succeeded
/home/apps/fpc/3.2.2/units/x86_64-linux/rtl/si_prc.o
attempt to open /home/apps/fpc/3.2.2/units/x86_64-linux/rtl/abitag.o succeeded
/home/apps/fpc/3.2.2/units/x86_64-linux/rtl/abitag.o
attempt to open test.o succeeded
test.o
attempt to open /home/apps/fpc/3.2.2/units/x86_64-linux/rtl/system.o succeeded
/home/apps/fpc/3.2.2/units/x86_64-linux/rtl/system.o
attempt to open dl.o succeeded
dl.o
attempt to open ./libdl.so failed
attempt to open ./libdl.a failed
attempt to open /usr/lib/x86_64-linux-gnu//libdl.so failed
attempt to open /usr/lib/x86_64-linux-gnu//libdl.a succeeded
/usr/lib/x86_64-linux-gnu//libdl.a
/usr/bin/ld: dl.o: in function `DL_$$_UNIXGETMODULEBYADDR$POINTER$POINTER$OPENSTRING':
dl.pp:(.text.n_dl_$$_unixgetmodulebyaddr$pointer$pointer$openstring+0x4c): undefined reference to `dladdr'
/usr/bin/ld: link errors found, deleting executable `test'
[0.031] Executing "/usr/bin/ld" with command line "-b elf64-x86-64 -m elf_x86_64  --trace --verbose --stats --dynamic-linker=/lib64/ld-linux-x86-64.so.2     -L. -o test -T link12679.res -e _dynamic_start"
[0.047] test.pas(6,1) Error: Error while linking
[0.047] test.pas(6,1) Fatal: There were 1 errors compiling module, stopping
[0.047] Fatal: Compilation aborted
Error: /home/apps/fpc/3.2.2/bin/x86_64-linux/ppcx64 returned an error exitcode


[robert rozee]

just tried your short program and compiling line. it is indeed an impressive output.

so the compiler does not find libdl.so.2, but does find libdl.a instead. libdl.a being a short text file containing:

Code: Text  [Select][+][-]

1. !<arch>

have just been discussing this with Fred vS. i was under the impression that when FPC encountered a shared library file called something like libdl.so.2 then it would use it, but that it could not distinguish between, for instance, libdl.so.2 and libdl.so.3. and also that when it finds libdl.so and libdl.so.2 then it would use libdl.so.

is my understanding of how external works wrong? is it that FPC simply can not see a library file that ends in .so.2 (or any other number)? i've had a hard time finding any useful documentation for external.


cheers,
rob   :-)

[TRon]

is my understanding of how external works wrong? is it that FPC simply can not see a library file that ends in .so.2 (or any other number)? i've had a hard time finding any useful documentation for external.

Correct. To my knowledge FPC does not search for such an extension. Even stronger if you specify it in your header then the compiler simply ignores it (by overwriting the extension with .so). You can try it yourself now knowing how to generate some (meaningful) output     It depends on you installing the dev package which does that labour (of figuring out which specific library to use) for you.

fwiw: Fred (but probably others as well) addressed that in a more recent thread (sorry can't seem to find it). If there is no dev package you can solve it yourself with a symlink using the unversioned name that links to the versioned name of the library.