Question to Gork AI:
Q: libc will release glibc_2.38. What are the difference vs glicbc_2.2.5? Could it be a problem for fpc using that glibc_2.38? It was ok with glibc_2.34.
A: Your situation involves a complex interplay between the Free Pascal Compiler (FPC), glibc versions, and symbol versioning, so let’s break it down and address your question about whether glibc 2.38 could pose problems when FPC doesn’t explicitly assign a glibc symbol version.
Background: Symbol Versioning and glibc
glibc uses symbol versioning to maintain backward compatibility. Each version of glibc (e.g., 2.2.5, 2.34, 2.38) introduces a symbol table with versioned symbols (e.g., malloc@GLIBC_2.2.5, malloc@GLIBC_2.34). When a program is linked against glibc, the linker (ld) assigns symbol versions to the functions it uses. If the code doesn’t explicitly specify a version (via something like __asm__(".symver malloc,malloc@GLIBC_2.2.5")), the linker defaults to the latest symbol version available in the glibc installed on the build system. This can lead to compatibility issues when the binary runs on a system with a different glibc version.
In your case:
FPC historically built against glibc 2.2.5 and doesn’t explicitly assign symbol versions.
Without explicit versioning, the linker on a system with glibc 2.34 or 2.38 will bind to symbols like malloc@GLIBC_2.34 or
malloc@GLIBC_2.38 if that’s the latest version present during compilation.
The glibc developers recommend explicitly assigning GLIBC_2.2.5 symbols in FPC’s code to ensure compatibility across all glibc versions, as 2.2.5 is the baseline that all later versions support.
Your Observations and Setup
glibc 2.34 Works Fine: You’ve noticed that building with glibc 2.34 doesn’t seem to cause issues. This is likely because glibc maintains strong backward compatibility, and symbols from 2.2.5 are still available in 2.34. Most core functions haven’t changed their ABI significantly, so binaries linked against 2.34 symbols often run fine on systems with 2.34 or newer glibc (as long as the runtime glibc is >= 2.2.5).
Will glibc 2.38 Cause Problems Without Explicit Versioning?
If FPC doesn’t assign symbol versions and you compile on a system with glibc 2.38, the linker will use the latest symbols (e.g., malloc@GLIBC_2.38). Here’s what could happen:
Potential Issues
Running on Older Systems:
If you distribute the binary to a system with glibc < 2.38 (e.g., 2.34 or 2.2.5), it will fail to run if it depends on symbols introduced or modified in 2.38 that aren’t present in earlier versions. For example, glibc 2.38 adds new functions like strlcpy and strlcat, and while these are unlikely to be used implicitly by FPC, any subtle ABI changes could break compatibility.
Historically, glibc avoids breaking ABI compatibility for existing symbols, but edge cases (e.g., changes in behavior or new dependencies) could still arise.
Deprecated Features:
glibc 2.38 deprecates features like libcrypt (requiring explicit enabling) and removes support for old mechanisms like
LD_ASSUME_KERNEL. If FPC’s runtime or generated code implicitly relies on these, you might encounter linker errors or runtime issues when building with 2.38.
Symbol Conflicts:
Without explicit versioning, a binary built with glibc 2.38 might request symbols that have evolved (e.g., improved thread-safety or new semantics). Running on a system with an older glibc could lead to with an older glibc could lead to unexpected behavior if the older symbol doesn’t match the expected implementation.
Why It Might Still Work
glibc’s commitment to backward compatibility means that symbols from 2.2.5 (e.g., malloc@GLIBC_2.2.5) are still provided in 2.38. If FPC only uses basic, stable functions (e.g., malloc, free, printf), the risk of incompatibility is low.
Your success with glibc 2.34 suggests that FPC’s usage of glibc is conservative, sticking to APIs that haven’t changed significantly.
-------------
So my conclusion: maybe it will be ok but maybe not.
Recent
