how a GUI application can warn of a GLIBC versioning error
lazarus / 32-Linux

----------------------------------------------------------------------
robert rozee · 2025-02-25 17:21

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.h
tml#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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
user@Mint19:~$ readelf -p .interp ./project.new  String dump of
section '.interp':  [     0]  /lib64/ld-
linux-x86-64.so.2 user@Mint19:~$ user@Mint19:~$ user@Mint19:~$
/lib64/ld-linux-x86-64.so.2 --list ./project.new
1>/dev/null./project.new: /lib/x86_64-linux-gnu/libc.so.6: version
`GLIBC_2.34' not found (required by ./project.new)user@Mint19:~$
user@Mint19:~$ 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 · 2025-02-26 01:07

Quote from: robert rozee on February 25, 2025, 06:21:01 pmany 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 · 2025-02-26 03:20

Quote from: TRon on February 26, 2025, 02:07:56 am 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 · 2025-02-26 11:27

Quote from: TRon on February 26, 2025, 02:07:56 amThe 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 · 2025-02-26 12:52

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 · 2025-03-01 11:13

Quote from: Fred vS on February 26, 2025, 01:52:48 pmMSEgui + 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.h
tml#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 · 2025-03-01 17:38

Quote from: robert rozee on March 01, 2025, 12:13:23 pmquite 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 · 2025-03-02 17:40

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 writeCode: Pascal  [Select][+][-]window.onload =
function(){var x1 = document.getElementById("main_content_section");
if (x1) { var x = document.getElementsByClassName("geshi");for (var i
= 0; i begin  writeln('GNU libc version:',
gnu_get_libc_version);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 · 2025-03-02 18:10

Quote from: Thaddy on March 02, 2025, 06:40:20 pmYou 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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i program
testprocess; uses cthreads, process; begin end.
----->

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i  $ ldd
/home/fred/testprocess        linux-vdso.so.1 (0x00007ffc00d2c000)   
   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2c7be00000) 
     /lib64/ld-linux-x86-64.so.2 (0x00007f2c7c226000)

----------------------------------------------------------------------
Thaddy · 2025-03-02 18:27

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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i 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 · 2025-03-02 18:29

Hello Thaddy.

Did you read my previous post + his last edit?

----------------------------------------------------------------------
Thaddy · 2025-03-02 18:32

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

----------------------------------------------------------------------
Fred vS · 2025-03-02 18:46

Quote from: Thaddy on March 02, 2025, 07:32:31 pmNothing 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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i $ nm -D
/home/fred/testprocess                 U dladdr@GLIBC_2.34           
    U dlclose@GLIBC_2.34                 U dlopen@GLIBC_2.34         
      U dlsym@GLIBC_2.34                 U
__errno_location@GLIBC_2.2.5                 w __gmon_start__        
       U __libc_start_main@GLIBC_2.34                 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 · 2025-03-02 19:10

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.