how a GUI application can warn of a GLIBC versioning error

[robert rozee]

hi all,
    this is a half-baked idea, but i wanted to get a little feedback. i was prompted by someone posting elsewhere on the forums about a GUI application that appeared to do nothing - yet another case of a GLIBC symbol versioning problem:
https://forum.lazarus.freepascal.org/index.php/topic,69945.msg547731.html#msg547731
(reply #13 from TCH)

after a bit of tinkering, i found out a way to establish if an ELF binary will fail with a GLIBC symbol versioning issue without needing to just try running it. because the ELF binary is not actually run, it is then possible to do a bit of a man-in-the-middle and give the user some feedback about what has happened - rather than them just clicking on an icon and nothing happening   

below shows the steps involved:

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

1. user@Mint19:~$ readelf -p .interp ./project.new
2.  
3. String dump of section '.interp':
4.   [     0]  /lib64/ld-linux-x86-64.so.2
5.  
6. user@Mint19:~$
7. user@Mint19:~$
8. user@Mint19:~$ /lib64/ld-linux-x86-64.so.2 --list ./project.new 1>/dev/null
9. ./project.new: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./project.new)
10. user@Mint19:~$
11. user@Mint19:~$
12. user@Mint19:~$ zenity --warning --no-wrap --text="/lib/x86_64-linux-gnu/libc.so.6:\n\nversion \`GLIBC_2.34\' not found\n(required by ./project.new)"

so readelf -p .interp [...] gets the path to the link/loader,
the link/loader, when passed the --list option 'reveals' the error message,
then we just need to do something with the message - zenity is just one possible option.

it would be relatively simple (under Linux) to bundle the above steps into a small 'container' FPC program that extracts the ELF binary into /tmp, then perform the checks to see if it will run without GLIBC symbol versioning issues - and run it if there are no issues. but, i am still not entirely happy with depending upon zenity to display a GUI window.

i feel that there must be something more ubiquitous than zenity... or some simple means of getting GTK2 and other graphics toolkits to pop up a simple GUI window without need for hundreds of K's of bloat added to one's binary.

any ideas?


cheers,
rob   :-)

[TRon]

any ideas?

The obvious: wouldn't such a small GUI program suffer the same libc faith ?

It is possible to create a GTK application without using LCL, similar as  is possible on Windows using the Windows API. See the FPC gtk2 package. However that does add the GTK dependency. To my knowledge there are two toolkits that are able to talk directly to X. One named fpGUI and the other MSEGUI. But in case that is also overkill there is a X11 package for FPCl. All mentions comes accompanied with examples.

[Fred vS]

To my knowledge there are two toolkits that are able to talk directly to X. One named fpGUI and the other MSEGUI. But in case that is also overkill there is a X11 package for FPCl. All mentions comes accompanied with examples.

Hello TRon and thanks to mention fpGUI and MSEgui.
But they are in the same boat: both need libc for Unix systems.

[robert rozee]

The obvious: wouldn't such a small GUI program suffer the same libc faith ?

not really: such a small GUI program could be crafted with appropriate internal symbol versioning to run successfully irrespective of the libc version. using zenity gets around the problem by it being part of the OS bundle, but we can't be 100% sure of zenity being universally available.

what we need is a lightweight means of passing a string (preferably that can be broken up with internal line breaks) to X11, GTK2, or whatever else, and for that string to be displayed in a popup window somewhere near the middle of the screen. strictly speaking, we don't even need to know what the user does in response to the popup window, all we need is to be confident our message gets to the user.

one idea i've toyed with is launching a terminal window, shrunk down to size with appropriate VT escape sequences, and displaying a message there.


cheers,
rob   :-)

[Fred vS]

Hello Rob.

You may also use MSEgui + fpc-ootb-from-the-site-you-know and who has all his glibc methods assigned with suffix @2.5.5...

[robert rozee]

MSEgui + fpc-ootb [...] who has all his glibc methods assigned with suffix @2.52.5...

quite true Fred, although here i'm considering solutions for bog-standard Lazarus and FPC, unpatched. like it or not, most folks are using the packages downloaded from SourceForge, and as a result generating ELF binaries that will fail silently on less-than-brand-new Linux distros. it is the "silently" that i'm looking at a solution for here. amusingly, the 'fail silently' even applies to the Lazarus 3.8 IDE itself that is pre-compiled and packaged up in the 3.8 .deb package. unless the 3.8 .deb package has been fixed since the below report?

https://forum.lazarus.freepascal.org/index.php/topic,69945.msg547731.html#msg547731
        By: TCH        Re: Lazarus Bugfix Release 3.8
        « Reply #13 on: February 19, 2025, 04:31:16 am »
                "The Debian package of Lazarus is still not usable on Debian 11:
                startlazarus: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by startlazarus)
                Can we request a package for Debian 11?


cheers,
rob   :-)

[Fred vS]

quite true Fred, although here i'm considering solutions for bog-standard Lazarus and FPC, unpatched. like it or not, most folks are using the packages downloaded from SourceForge,

Hello Rob.

Yes I know and I hope that one day the fpc devs will agree to resign themselves to reality and follow the advice of the libc developers. 

OK, I'm leaving...   

[Thaddy]

You can run ldd --version in a Tprocess at program startup.
Actually this is plain oversight from the libc unit vs library discussion.
You should be able to write

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

1. begin
2.   writeln('GNU libc version:', gnu_get_libc_version);
3. end.

But it happens that that header is not implemented anywhere else but in the libc unit, which is deprecated.
This should be easy to fix.

[Fred vS]

You can run ldd --version in a Tprocess at program startup.

But you won't be able to do anything if the libc can't be loaded...

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

1. program testprocess;
2.  
3. uses cthreads, process;
4.  
5. begin end.

----->

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

1.  $ ldd /home/fred/testprocess
2.         linux-vdso.so.1 (0x00007ffc00d2c000)
3.         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2c7be00000)
4.         /lib64/ld-linux-x86-64.so.2 (0x00007f2c7c226000)

[Thaddy]

As I editted: this should be an easy fix, it is just a part of the libc UNIT that is not ported, The signature is quite simply:

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

1. function gnu_get_libc_version:PAnsiChar;cdecl;external clib name 'gnu_get_libc_version';

and that should probably show up in BaseUnix or close to that. It is simply not ported by mistake, but not a drama.
You may report this as a bug, because it is. ( a small one)

[Fred vS]

Hello Thaddy.

Did you read my previous post + his last edit?

[Thaddy]

Nothing to do with the Debian version if that is what you mean.

[Fred vS]

Nothing to do with the Debian version if that is what you mean.

?

Here lists the symbols used by the testprocess code in  my previous post.
You will always need the problematic GLIBC_2.34 and it will not run on a system that dont have that table yet.

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

1. $ nm -D /home/fred/testprocess
2.                  U dladdr@GLIBC_2.34
3.                  U dlclose@GLIBC_2.34
4.                  U dlopen@GLIBC_2.34
5.                  U dlsym@GLIBC_2.34
6.                  U __errno_location@GLIBC_2.2.5
7.                  w __gmon_start__
8.                  U __libc_start_main@GLIBC_2.34
9.                  U sched_yield@GLIBC_2.2.5

And it is why the libc devs advised, for fpc, to assign @GLIBC_2.2.5 symbol table for each libc method.

But all this has already been discussed millions of times and it always ends in a fight.

 

[Fred vS]

The future (for this year) new symbol table of libc is GLIBC_2.42.

And this table will not be 100% compatible (copy memory, init file, etc) with the GLIBC_2.2.5 table used by fpc code since the beginning and that was never updated for new tables.
So if fpc does not do something all the fpc programs will have trouble if compiled with that table.