Forum > Linux

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

(1/6) > >>

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:

--- Quote from: dieselnutjob on November 05, 2024, 02:17:00 pm ---I think that it's because I compiled on bookworm whereas they have bullseye (from memory.

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


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

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


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

--- End quote ---
It is because of libc.


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

--- End quote ---
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  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---function dlopen(Name : PChar; Flags : longint) : Pointer; cdecl;          external libdl name 'dlopen@GLIBC_2.17';
Raise that error (the same for each symbol table used and for each method):

--- Code: Bash  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---fpc-src/rtl/units/aarch64-linux/dynlibs.s: Assembler messages:fpc-src/rtl/units/aarch64-linux/dynlibs.s:16: Error: unexpected characters following instruction    at operand 1 -- `bl dlopen@GLIBC_2.17'dynlibs.inc(74,1) Error: Error while assembling exitcode 1dynlibs.inc(74,1) Fatal: There were 2 errors compiling module, stopping 
Here result of nm -D libc.so.6

--- Code: Bash  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---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.


--- Quote ---- native or cross compiling ?
--- End quote ---
Native, Raspberry Pi 3 b with 2024-07-04-raspios-bookworm-arm64.


--- Quote ---- is it specific to 3.2.4 ?
--- End quote ---
Same with fpc 3.2.2. from fpc download.


--- Quote ---- did you used/applied any other solution with regards to libc ?
--- End quote ---
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.


--- Quote ---when cross-compiling with 3.2.2 to raspbian 12
--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page

Go to full version