Recent

Author Topic: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found  (Read 63999 times)

robert rozee

  • Full Member
  • ***
  • Posts: 205
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #225 on: October 25, 2023, 10:57:11 pm »
there is also a problem with a couple of symbols, setenv and __cxa_finalize. both seem to be referenced from unknown places, with only my fake libdl.so catching them.

Might be ld-linux or glibc startup code. Not necessarily FPC.

my posting you are replying to was nearly 3 months ago, the world has moved on quite a bit since then! the more recent pd_external() patch manages to catch pretty much everything that earlier solutions missed.

although i do still have a soft spot for the fake libdl.so solution. it was elegant, but alas went against the advice of the GLIBC developers   O:-)


cheers,
rob   :-)

Fred vS

  • Hero Member
  • *****
  • Posts: 3475
    • StrumPract is the musicians best friend
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #226 on: January 14, 2025, 02:35:40 pm »
... the advice of the GLIBC developers   O:-)

If I remember correctly, when you asked the GLIBC developers, their advice for fpc was to use the signed symbol table (2.2.5) for the declaration of each GLIBC method because if you don't, the linker will do it for you using the latest table installed on the build system.
And it could be that this table is not compatible with the table that fpc (2.2.5) has been using since the beginning.  Also link with 'libdl.so.2' (like Delphi, gcc, clang and others can do).
« Last Edit: January 14, 2025, 02:44:31 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

robert rozee

  • Full Member
  • ***
  • Posts: 205
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #227 on: January 14, 2025, 03:19:56 pm »
... the advice of the GLIBC developers   O:-)

If I remember correctly, when you asked the GLIBC developers, their advice for fpc was to use the signed symbol table (2.2.5) for the declaration of each GLIBC method because if you don't, the linker will do it for you using the latest table installed on the build system.
And it could be that this table is not compatible with the table that fpc (2.2.5) has been using since the beginning.  Also link with 'libdl.so.2' (like Delphi, gcc, clang and others can do).

it was quite a while back! as i recall, some of the GLIBC developers thought that without any version numbers specified, the linker should default to the earliest version available for each symbol, but then this proved to not be the case. they then went on to say that FPC should use the earliest version numbers available for each symbol. these numbers are available from an examination of libc.so.6 on the running system, which is what my MakeBase program in the first posting of the thread (https://forum.lazarus.freepascal.org/index.php/topic,64731.0.html) does. as i recall, this just happens to be 2.2.5 for all(?) of the libc calls that FPC currently uses. the GLIBC developers also promised that for the life of the x86_64 platform none of the existing versioned GLIBC symbols would be depreciated - that is if some_symbol@GLIBC_2.x.y exists in the x86_64 GLIBC today, the exact same symbol and version will always exist in every future x86_64 GLIBC released.


cheers,
rob   :-)


addendum: attached .zip file containing a list of x86_64 GLIBC symbols with their version numbers
« Last Edit: January 14, 2025, 03:23:57 pm by robert rozee »

Fred vS

  • Hero Member
  • *****
  • Posts: 3475
    • StrumPract is the musicians best friend
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #228 on: January 14, 2025, 03:39:31 pm »
... this just happens to be 2.2.5 for all(?) of the libc calls that FPC currently uses.

Yes, all this is used by this fpc-patched and it works perfectly on very old and very new distributions.

For Linux i386 32-bit, it is mainly the GLIBC_2.0. table that is used but also GLIBC_2.1. and GLIBC_2.3.

Note that for the latest libc.so in Linux ARM 32-bit (Rpi) there could be the same problem as for x86_64 `GLIBC_2.34' not found because they introduce this new 2.34 table. For ARM 32, the table that needs to be assigned is mainly GLIBC_2.4. with also some exceptions.
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1791
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #229 on: January 14, 2025, 04:00:03 pm »
Included a list of versions for more architectures.

Fred vS

  • Hero Member
  • *****
  • Posts: 3475
    • StrumPract is the musicians best friend
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #230 on: January 14, 2025, 04:04:21 pm »
Included a list of versions for more architectures.

Hello Don.
I did try to assign signed table for Linux aarch64 but it seems that fpc does not allow this, there was error at compilation.
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

robert rozee

  • Full Member
  • ***
  • Posts: 205
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #231 on: January 14, 2025, 04:31:04 pm »
Included a list of versions for more architectures.

rather than hard-coding these into the compiler's source as a giant table, is it surely not easier to just have the FPC compiler itself generate the list from libc.so.6 (using readelf and code similar to my MakeBase utility) each time the compiler is run and stash away the list in a safe place? i've used the /tmp directory as all linux systems should have this available; in actual fact the compiler would only need to regenerate the list on the odd occasions when it is missing from /tmp after a reboot.

from what the GLIBC developers have said, i am reasonably confident that the BASE version numbers will always be available from any libc.so.6.


cheers,
rob   :-)

Fred vS

  • Hero Member
  • *****
  • Posts: 3475
    • StrumPract is the musicians best friend
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #232 on: January 14, 2025, 04:51:48 pm »
Included a list of versions for more architectures.
I like it!
Maybe only use the libc methods used by fpc+rtl?
[EDIT] Or only a table of the methods that dont use the "default base table" of the architecture?
« Last Edit: January 14, 2025, 04:57:08 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

WayneSherman

  • Sr. Member
  • ****
  • Posts: 254
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #233 on: January 14, 2025, 05:03:53 pm »
rather than hard-coding these into the compiler's source as a giant table, is it surely not easier to just have the FPC compiler itself generate the list from libc.so.6 (using readelf and code...from what the GLIBC developers have said, i am reasonably confident that the BASE version numbers will always be available from any libc.so.6.

Even better is to parse the version data from the canonical source rather than an arbitrary compiled libc.so binary.

x86_64 libc ABI symbol versions are in this directory:
[glibc.git] / sysdeps / unix / sysv / linux / x86_64 / 64 /
(see *.abilist files)

aarch64 libc ABI symbol versions are in this directory:
[glibc.git] / sysdeps / unix / sysv / linux / aarch64 /
(see *.abilist files)

arm little-endian libc ABI symbol versions are in this directory:
[glibc.git] / sysdeps / unix / sysv / linux / arm / le /
(see *.abilist files)
etc...

DonAlfredo made an auto *.abilist downloader and processor which generates a glibc.inc file:
https://github.com/LongDirtyAnimAlf/fpcupdeluxe/tree/master/fpcuptools/glibc
« Last Edit: January 14, 2025, 05:10:17 pm by WayneSherman »

Fred vS

  • Hero Member
  • *****
  • Posts: 3475
    • StrumPract is the musicians best friend
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #234 on: January 14, 2025, 05:37:31 pm »
Here the list of all libc methods used by Lazarus, only 35 so a inc table should not be big.
Code: Pascal  [Select][+][-]
  1. fred@fred-IdeaPad:~$ readelf -s /home/fred/fpcupdeluxe/lazarus/lazarus | grep GLIBC
  2.    105: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlopen@GLIBC_2.34 (3)
  3.    194: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND iconv@GLIBC_2.2.5 (2)
  4.    269: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND read@GLIBC_2.2.5 (2)
  5.    516: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlsym@GLIBC_2.34 (3)
  6.    836: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND close@GLIBC_2.2.5 (2)
  7.    937: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dladdr@GLIBC_2.34 (3)
  8.   1150: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fcntl@GLIBC_2.2.5 (2)
  9.   1285: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND write@GLIBC_2.2.5 (2)
  10. 320319: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND wcrtomb@GLIBC_2.2.5
  11. 334858: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND openlog@GLIBC_2.2.5
  12. 350969: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND tcsetattr@GLIBC_2.2.5
  13. 353312: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND tcgetattr@GLIBC_2.2.5
  14. 380738: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND closelog@GLIBC_2.2.5
  15. 392973: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mbrtowc@GLIBC_2.2.5
  16. 422501: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND iconv@GLIBC_2.2.5
  17. 457832: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND read@GLIBC_2.2.5
  18. 505452: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND wcscoll@GLIBC_2.2.5
  19. 515596: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlerror@GLIBC_2.34
  20. 535362: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND ptsname_r@GLIBC_2.2.5
  21. 538682: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND grantpt@GLIBC_2.2.5
  22. 556695: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND syslog@GLIBC_2.2.5
  23. 574654: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND openpty@GLIBC_2.34
  24. 640053: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND towlower@GLIBC_2.2.5
  25. 745365: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlclose@GLIBC_2.34
  26. 750534: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND login_tty@GLIBC_2.34
  27. 878309: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND setenv@GLIBC_2.2.5
  28. 895759: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND setlocale@GLIBC_2.2.5
  29. 897036: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strcoll@GLIBC_2.2.5
  30. 912669: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mbrlen@GLIBC_2.2.5
  31. 939815: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fcntl@GLIBC_2.2.5
  32. 966508: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND sysconf@GLIBC_2.2.5
  33. 981062: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND unlockpt@GLIBC_2.2.5
  34. 1003778: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND write@GLIBC_2.2.5
  35. 1015003: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND towupper@GLIBC_2.2.5

Also the new last distros do not provide a symlink libdl.so to libdl.so.2, even with the -dev package.
So always be sure that a symlink libdl.so exists, if not, create it before compilation.
(Of course it would be better that fpc links to libdl.so.2 directly but it is not possible with fpc.)
« Last Edit: January 14, 2025, 06:13:25 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

WayneSherman

  • Sr. Member
  • ****
  • Posts: 254
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #235 on: January 14, 2025, 06:09:10 pm »
glibc symbols are optionally used by:
  the fpc compiler (edited: apparently the compiler does not use any external libc symbols)
  the fpc packages
  the run time library (RTL)
  other "client" software of the fpc compiler and RTL

In order to get something like this merged into FPC will require a multi-step process.  Maybe something like this:

1) Discuss the idea and proposed plan on the FPC developer mailing list.

2) In the fpc packages and RTL, find all "external" declarations to glibc symbols and consolidate them into one folder and set of files. (A central folder for the glibc header conversion)

3) Modify all fpc packages and RTL units which reference libc symbols.  Delete their local "external" libc symbol declarations and add to their "uses" the correct file in the consolidated glibc interfaces folder.

NOTE: items 2, and 3 above should not be very controversial and this type of refactoring arguably should be done anyway for good code organization and maintenance

4) Add symbol versioning options to the consolidated libc declarations using conditional compilation directives (e.g. IFDEF, DEFINE) which allow the use of unversioned glibc symbols or versioned glibc symbols. This allows the choice to be made at compile time and/or hard coded in project source files if desired. (unversioned is how it currently works with the linker versioning the symbols at link time using the what is found in the system libc.so.6 file) (EDITED - since the compiler doesn't use libc symbols directly then conditional compilation directives should be all that is needed to enable and disable libc symbol versions)

Start with the linux x86_64 architecture and follow with the other architectures after a period of testing.

(updated with various corrections and clarifications)
« Last Edit: January 14, 2025, 07:08:57 pm by WayneSherman »

Fred vS

  • Hero Member
  • *****
  • Posts: 3475
    • StrumPract is the musicians best friend
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #236 on: January 14, 2025, 06:17:27 pm »
glibc symbols are optionally used by:
-  the fpc compiler
Hum, short correction before the screams, fpc himself does not use glibc.   :)
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

WayneSherman

  • Sr. Member
  • ****
  • Posts: 254
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #237 on: January 14, 2025, 06:38:00 pm »
glibc symbols are optionally used by:
-  the fpc compiler
Hum, short correction before the screams, fpc himself does not use glibc.   :)

In that case the compiler itself doesn't need to change, just the RTL (and packages). Using conditional compilation directives like IFDEF and DEFINE should be all that is needed to enable or disable libc symbol versioning.
« Last Edit: January 14, 2025, 07:06:47 pm by WayneSherman »

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1791
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #238 on: January 14, 2025, 07:07:15 pm »
I heard last year that versioned linking would be implemented by one the the compiler devs. That is why I stopped myself in diving deeper into this.
However, I think that the addition of versioned symbols should be done by the compiler. If done like this, all compiled sources will be versioned without changes needed into these sources.

Fred vS

  • Hero Member
  • *****
  • Posts: 3475
    • StrumPract is the musicians best friend
Re: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
« Reply #239 on: January 14, 2025, 07:11:38 pm »
In that case the compiler itself doesn't need to change, just the RTL. Using conditional compilation directives like IFDEF and DEFINE should be all that is needed to enable or disable libc symbol versioning.

Yes, it is the simpler way that works perfectly.
Something like this in each unit that uses libc, for example in dl.pp
Code: Pascal  [Select][+][-]
  1. unit dl;
  2.  
  3. interface
  4.  
  5. const
  6.   // allow to assign proper signed symbol table name for a libc.so.6 method
  7.   {$if defined(linux) and defined(cpux86_64)}
  8.   LIBC_SUFFIX = '@GLIBC_2.2.5';
  9.   {$else}
  10.   {$if defined(linux) and defined(cpuaarch64)}
  11.   LIBC_SUFFIX = '@GLIBC_2.17';
  12.   {$else}
  13.   {$if defined(linux) and defined(cpuarm)}
  14.   LIBC_SUFFIX =  '@GLIBC_2.4';
  15.   {$else}
  16.   {$if defined(linux) and defined(cpui386)}
  17.   LIBC_SUFFIX = '@GLIBC_2.0';
  18.   {$else}
  19.   LIBC_SUFFIX = '';
  20.   {$endif}
  21.   {$endif}
  22.   {$endif}
  23.   {$endif}
  24.  
  25. ...
  26.  
  27. function dlopen(Name : PChar; Flags : longint) : Pointer; cdecl; external libdl name 'dlopen'  + LIBC_SUFFIX ;
  28. function dlsym(Lib : Pointer; Name : Pchar) : Pointer; cdecl; external Libdl name 'dlsym'  + LIBC_SUFFIX ;
  29.  
« Last Edit: January 14, 2025, 07:24:10 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

 

TinyPortal © 2005-2018