FPC 3.2.2 / Lazarus 2.2.6 patch for GLIBC_2.34 versioning issue

[Fred vS]

In case you asked it to me too  , I will vote for 1. for Linux amd64 and assign GLIBC_2.2.5 for each libc method used by fpc.
Beause fpc was created using this table and never updated for new table and mainly because I did test it deeply and it works perfectly.

How's holding off to a 18 year old version of glibc good?

Linking to the older symbols doesn't mean you get old, buggy, or insecure implementations.  The symbol versions are intended to provide a stable interface (API/ABI) for backwards compatibility.  The underlying implementations still get bug and security fixes.

Bravo! 

[WayneSherman]

In the case of fpc and the rtl using the glibc library on Linux (x86_64):
The pascal header conversion and code that calls library functions and code that references external symbols was written and tested against a specific version of glibc with specific documented behavior for those functions and symbols.

1. Do you think the fpc and rtl source code declarations should be specifically pinned to those versions of the glibc functions they were originally written to work with? (i.e. declare the specific glibc .so version and the specific versions of the external symbols in the fpc/rtl source code)

2. Do you think the fpc and rtl glibc source code declarations should not specify any versions and allow the compiled binaries to get specific .so file version and symbol versions from the static linker at build time (which uses the glibc library present on the system at build time)?

or
3. Should there be the ability to choose between the two options above when compiling fpc/rtl?

What do other compilers do in this regard? I feel like no. 3 would be the best option, but by default have the behavior of no. 2.

Typically when building C programs, you are using the matching header files for the installed glibc version, and the linker is used to embed the SONAME (which includes the major version) and the symbol versions (from the installed glibc) in the executable.  For software that only needs to run on selected systems with the same or future versions of glibc, this works. (Note that fpc has a problem here because there is not a new header conversion for each release of glibc.  So there could be mismatches and hard to find bugs if fpc uses old header declarations with new versions of symbols in glibc)

For software that needs to run on a variety of distros (which might include older ones), a developer might do the following:

• Develop and test on a modern distro with a modern tool chain using the newest .so version and newest symbol versions exposed by glibc.
• Copy the project to an old distro and jump through hoops trying to get all the dependencies installed without conflicts and trying to get it to build cleanly.  The executable gets the older .so version and older symbol versions embedded by the linker.
• Perform little or no testing on the old distro since it's main purpose is to 1) use the correct C headers for the older glibc and 2) get the older symbol versions embedded in the executable. (some developers have crafted a VM or container specifically setup with an old glibc for building)

For fpc, I think a better way is to:

• Develop and test on a modern distro with a modern tool chain and recent glibc using a specified SONAME which includes the major version and specified (older) symbol versions which are still exposed by the recent glibc.
• done.

There is no need to craft a special environment just for building and no need to copy the project to an old distro and jump through hoops.  The executable should already be compatible with new and older glibc releases.  (of course testing would be important on any distro you plan to target)

(EDITED to clarify the the SONAME of a library includes the major version. According to semantic versioning, the "Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API.")

[Fred vS]

For fpc, I think a better way is to:

• Develop and test on a modern distro with a modern tool chain and recent glibc using a specified .so version and specified (older) symbol versions which are still exposed by the recent glibc.
• done.

There is no need to craft a special environment just for building and no need to copy the project to an old distro and jump through hoops.  The executable should already be compatible with new and older glibc releases.  (of course testing would be important on any distro you plan to target)

The problem is that to know what version is glibc you need to load it first then get the version number.
And it must be done before compiling.

[WayneSherman]

2. Do you think the fpc and rtl glibc source code declarations should not specify any versions and allow the compiled binaries to get specific .so file version and symbol versions from the static linker at build time (which uses the glibc library present on the system at build time)?

Sorry to be the boring ones again but there is no specific .so file for libc.
There is libc.so.6 and each new version has still the same name libc.so.6 but with new symbols tables.

(from ChatGPT)
"The transition from libc.so.5 (which belonged to the older Linux libc) to libc.so.6 (which belongs to GNU C Library or glibc) occurred in 1997. This was a major shift in the Linux ecosystem and coincided with the release of glibc 2.0. This transition required programs that had been compiled against libc.so.5 to be recompiled against the newer libc.so.6."

The reason the .so filename version does not have to change often is because internal symbol versioning has worked well for API/ABI changes.  In the future, major changes might justify another file name change to libc.so.7.  But a change in the major version signifies an API change so it isn't safe to assume that libc.so.7 would be drop-in compatible with libc.so.6.

[Fred vS]

The last, after this, I leave you in
peace.

Our friend said: “Talk is cheap. Show me the code.”

In last release of LazPaint:
https://github.com/bgrabitmap/lazpaint/releases

you may test, on very old and very new Linux distros, this:
lazpaint7.2.2_linux64_timeless_no_install.tar.gz

It uses signed symbol @GLIBC_2.2.5. for all glibc methods and link with 'libdl.so.2'.