Strict glibc version dependencies (discussion)

[maxirmx]

Just a summary. Open to discussion and any siggestions

GLIBC if forward compatible, meaning that shared objects and executables (including tebako packages) build against specific versions of GLIBC will work on systems where the higher version is installed.

For example, ABI pthread_join@@GLIBC_2.2.5 means that GLIBC version 2.2.5 or above is required at the target system.

However, GLIBC includes internal APIs that are not guaranteed to be stable. This API is intended to be used for calls accross GLIBC components (for example for call from a function placed in libc.so to a function at libpthread.so

Internal functions have ABI like __pthread_unwind@@GLIBC_PRIVATE where GLIBC_PRIVATE suffix enforces strict GLIBC version dependency and the application fails to start if GLIBC version is different from the build system.

As of version 0.8.5 tebako produces linux-gnu packages with three problem references:

0000000000000000  w    F *UND*  0000000000000000              __pthread_unwind@@GLIBC_PRIVATE
0000000000000000       F *UND*  0000000000000000              __pthread_get_minstack@@GLIBC_PRIVATE
0000000000000000         *UND*  0000000000000000              errno@@GLIBC_PRIVATE

These references originate original Ruby source and are related to mjit support

There is a solution proposed by @d4rky-pl (#190 (comment)) and implemented in #195. This solution works with gnu toolchain (not cland/llvm) and may have other limitations. The plan is to have it implemented in tebako 0.8.6 as experimental feature.

I see it (relatively) safe at lease for Ubuntu buillds because of change explained at the first paragraph here: https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html IMHO tebako packages with removed GLIBC_PRIVATE will work on systems GLIBC 2.34+

It is worth noting that the issue won't exist for tebako packages built with GLIBC version 2.34+ due to changed GLIBC architecture (prcatically Ubuntu 22+)

[laurent-martin]

I wonder if the alpine version could be statically linked with libc.musl-x86_64.
So, it can also be executed on other system versions (without libc.musl-x86_64) ?

[maxirmx]

I wonder if the alpine version could be statically linked with libc.musl-x86_64. So, it can also be executed on other system versions (without libc.musl-x86_64) ?

I tried it for gnu linux. It worked when static linking was applied (--static flag)
It is possible to create highly portable package this way unless it includes gems with native extensions (== shared libraries).
If the package has bundled shared libraries it has to call dl that is always dl.so and it breaks the whole concept.

You are right, musl may suit this approach better. I will make a test.