/lib/arm-linux-gnueabihf/libc.so.6: version GLIBC_2.34 not found

[dieselnutjob]

I compiled my fpgui program on my raspberry Pi and gave it to a customer, but they get "/lib/arm-linux-gnueabihf/libc.so.6: version GLIBC_2.34 not found" on their Pi.

I think that it's because I compiled on bookworm whereas they have bullseye (from memory.

So I reinstalled bullseye on my pi and recompiled and now it works on the customer's pi.

I guess that this is a freepascal problem rather than an fpgui one?

I'm not sure why this happens given that the version of fpc are very similar from bullseye to bookworm.

Is there a way to configure fpc to make the binaries more backwards compatible?

thanks

[TRon]

I think that it's because I compiled on bookworm whereas they have bullseye (from memory.

Correct as there is a version difference for libc between those two releases.

I guess that this is a freepascal problem rather than an fpgui one?

It is neither. In origin it is a libc issue (actually linking against specific symbol versions). Every compiler has to deal with it.

I'm not sure why this happens given that the version of fpc are very similar from bullseye to bookworm.

It is because of libc.

Is there a way to configure fpc to make the binaries more backwards compatible?

See this very long thread for different offered solutions/workarounds.

afaik it is planned to have a more permanent solution though I do not know the current status for that.

For now, compiling on/for an older distro (like you did) is the easiest way to 'fix' the issue.

[Fred vS]

For Linux Aarch64 there is a problem (bug?): assigning a symbol table for a method raise a error at linking using fpc 3.2.4.

For example this:

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

1. function dlopen(Name : PChar; Flags : longint) : Pointer; cdecl;
2.           external libdl name 'dlopen@GLIBC_2.17';

Raise that error (the same for each symbol table used and for each method):

Code: Bash  [Select][+][-]

1. fpc-src/rtl/units/aarch64-linux/dynlibs.s: Assembler messages:
2. fpc-src/rtl/units/aarch64-linux/dynlibs.s:16: Error: unexpected characters following instruction
3.     at operand 1 -- `bl dlopen@GLIBC_2.17'
4. dynlibs.inc(74,1) Error: Error while assembling exitcode 1
5. dynlibs.inc(74,1) Fatal: There were 2 errors compiling module, stopping
6.  

Here result of nm -D libc.so.6

Code: Bash  [Select][+][-]

1. 000000000007ae80 T dlopen@GLIBC_2.17

Note that this does not appear on Linux amd64.

[TRon]

@Fred vS
Can you share ?
- native or cross compiling ? and in case native then the host is raspbian (or whatever they named it) or something else ?
- is it specific to 3.2.4 ?
- did you used/applied any other solution with regards to libc ? in case yes, which one ?

fwiw: a quick test with fpcup shows that this issue does not seem to appear when cross-compiling with 3.2.2 to raspbian 12 (but I also know that fpcup has some patches for both compiler and libc although I do not know if those are applied).

Based on the answers I am able to test/verify and provide more meaningful feedback.

[Fred vS]

Hello TRon.

- native or cross compiling ?

Native, Raspberry Pi 3 b with 2024-07-04-raspios-bookworm-arm64.

- is it specific to 3.2.4 ?

Same with fpc 3.2.2. from fpc download.

- did you used/applied any other solution with regards to libc ?

I did try to compile fpc src 3.2.4 with all the libc methods with assigned symbol table, like I did for amd64, using official fpc 3.2.2. compiler.

But without luck for aarch64.

when cross-compiling with 3.2.2 to raspbian 12

I can cross-compile app from Linux amd64 to Linux aarch64.
Sadly I was never able to cross-compile fpc himself and if it is possible, of course I am more than interested to know the steps to do it.

[Thaddy]

Sadly I was never able to cross-compile fpc himself and if it is possible, of course I am more than interested to know the steps to do it.

Well, I tried to replicate that Fred, but... I can't...
The screenshot is just to prove I am too lazy to run up the stairs... btw, zero 2 W running aarch64 testing some other issue.

[Thaddy]

And compiled natively. You only need the 3.2.2 compiler, and that you can get from the default ubuntu or debian repositories.

[Fred vS]

And compiled natively. You only need the 3.2.2 compiler, and that you can get from the default ubuntu or debian repositories.

Hello Thaddy.

Not sure to understand.
Are you able to compile fpc 3.2.4 src after adding a symbol table for some libc methods used by fpc-source?
Like the one in my first post in dl.pp:
 

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

1.   function dlopen(Name : PChar; Flags : longint) : Pointer; cdecl;
2.               external libdl name 'dlopen@GLIBC_2.17';

Of course I can compile fpc 3.2.4 on a native rpi using fpc 3.2.2 but I cannot compile it if @GLIBC_2.17 is added for name of some libc methods.

And on amd64 it is allowed.

[Thaddy]

Not 3.2.4 but trunk/main

[marcov]

If the behaviour doesn't change with -Aas, the problem is not in FPC but in the assembler.

If it does change, it might be a problem in the ARM internal assembler (the object file/binwriter).

[Fred vS]

If the behaviour doesn't change with -Aas,

Hmm, when trying to compile fpc 3.2.4 on a native aarch64 rpi, where should we add -Aas, something like this in the script?:

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

1. make all FPC=$COMPILER OPT="-Aas"

And if there are problems with aarch64 assembler from a native aarch64 rpi, could a cross-compilation from amd64 to aarch64 be the solution (maybe stupid suggestion, sorry if so)?

[TRon]

Hmm, when trying to compile fpc 3.2.4 on a native aarch64 rpi, where should we add -Aas, something like this in the script?:

Wait. Stop the presses ! 

You mean you got that error that you described when natively building the compiler itself when using the makefile ? (that was not clear for me on earlier descriptions perhaps I overlooked)

And if there are problems with aarch64 assembler from a native aarch64 rpi, could a cross-compilation from amd64 to aarch64 be the solution (maybe stupid suggestion, sorry if so)?

Well, I am able to cross-compile the example code without issues (whether it actually works or not I have not tested yet but will try to do when back home).

Hmm, when trying to compile fpc 3.2.4 on a native aarch64 rpi, where should we add -Aas, something like this in the script?:

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

1. make all FPC=$COMPILER OPT="-Aas"

it actually is make FPC="/full/path/and/filename/to/your/fpc/executable" OPT="-Aas"

[Thaddy]

Which is basicaly what I wrote.
Note that the fix is fairly recent (days, not weeks)and does not apply to 3.2.4.(yet, maybe a candidate for back porting)

[Fred vS]

Hmm, when trying to compile fpc 3.2.4 on a native aarch64 rpi, where should we add -Aas, something like this in the script?:

Wait. Stop the presses ! 

You mean you got that error that you described when natively building the compiler itself when using the makefile ? (that was not clear for me on earlier descriptions perhaps I overlooked)

OK, sorry if I was not clear.
The goal is to compile fpc 3.2.4, with some changes in the name of all clib methods (added @GLIBC_2.17 to assign the correct symbol table and not let the linker do it).
The script to compile fpc that I used on the native rpi aarch64 is this:

Code: Bash  [Select][+][-]

1. #!/bin/sh
2. COMPILER=fpc
3. make clean
4. make all FPC=$COMPILER OPT="-Fl/usr/local/lib"
5. make FPC=$COMPILER install INSTALL_PREFIX=/home/fred/fpc-work/usr

And with this script, the compilation fails with that message (like explained in previous post):

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

1.    fpc-src/rtl/units/aarch64-linux/dynlibs.s: Assembler messages:
2.     fpc-src/rtl/units/aarch64-linux/dynlibs.s:16: Error: unexpected characters following instruction
3.         at operand 1 -- `bl dlopen@GLIBC_2.17'
4.    dynlibs.inc(74,1) Error: Error while assembling exitcode 1
5.    dynlibs.inc(74,1) Fatal: There were 2 errors compiling module, stopping

Clearly, the assembler does not like that @GLIBC_2.17 addition, maybe the unexpected character is @?

Note that without that change, the compilation is ok.
Note too that compiling the fpc source with assigned symbol table on Linux amd64 cpu is working like charm (and solves lot of things).

[TRon]

No need to be sorry about Fred. It was entirely my fault for not properly reading what you wrote earlier.

Nevertheless thank you for the further clarifications, it is al crispy clear now what needs to be tested/verified.

Did you already had a chance to try the option that was suggested by MarcoV and/or try a cross-build ? (both might be worth a shot).

@Thaddy: Did you meant that this particular issue was addressed in trunk recently ? (I ask because I must have missed it)