hi incendio,
assuming the problem you are encountering relates to the console error message /
lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found the
simplest solution is to install Lazarus/FPC using the FPCUpdeluxe application found here:
https://github.com/LongDirtyAnimAlf/fpcupdeluxewith the appropriate settings selected in FPCUpdeluxe to enable symbol name/version translation. i have
not done this myself (i use other methods), but have every confidence that it should work.
with Lazarus/FPC appropriately installed using FPCUpdeluxe, generated executable files will then run on older Linux distros without this issue. it would perhaps be helpful if someone could post a walk-through on how to do the installation.
TRon? (oops, my mistake, DonAlfredo is the FPCUpdeluxe author)a simplified background:
the GLIBC authors intended that every call to a GLIBC function
should specify both a
function name and a
version number, with the two separated with an "@" symbol. for example, "
dlopen@GLIBC_2.2.5" specifies the function
dlopen that was first introduced with
GLIBC_2.2.5 (version 2.2.5 of GLIBC). this scheme allowed for new versions of a function to be added over time without breaking backward compatibility; when new versions of a function were deployed, old version(s) would
always be kept available within GLIBC. the GLIBC developers have assured me that once a function/version combination is introduced it will
never be removed for the life of the target system (for us this is linux on i386 or AMD64).
the fundamental problem arose when the Lazarus authors decided it would be a good idea to leave out the version numbers from all their source code. this 'kinda worked', in that when an executable was created the linker (which is neither a part of GLIBC nor FPC) would
automatically append version numbers to GLIBC function names, using the
latest it could find on the computer that was building said executable. as far as i have been able to determine, the linker's choice to always use the latest rather than the oldest version seems to be arbitrary.
in the case of
dlopen there are at least two version of the function:
dlopen@GLIBC_2.2.5
dlopen@GLIBC_2.34when the Lazarus libraries that use
dlopen were written, only the 2.2.5 version existed. but then in recent years a newer version of
dlopen, 2.34, has been added to GLIBC. the Lazarus libraries know nothing of the 2.34 version, but nonetheless end up being linked to it. purely by good fortune, the 2.34 version of
dlopen is functionally compatible with the 2.2.5 version.
the same applies to dozens of other functions in GLIBC, and there is
no guarantee going forward that an incompatible version of some existing function will never be introduced; if this happens, Lazarus will break.
cheers,
rob :-)
Recent
