Build against an older libc, keep the newest in the runtime closure

[SomeoneSerge]

Issue description

Libc and libstdc++ compatibility is a dominating factor in how severe is the effect of allowing impure dependencies such as OpenGL, OpenCL, Vulkan, or CUDA drivers. Ultimately, the heuristic is: build against the oldest library you can, load the most recent at runtime. This practice is widely followed in other distributions and is important e.g. for the "manywheel" standard in python packaging.

Currently, Nixpkgs pins a single fairly recent version of glibc and builds every package against that. A suggestion that has been at least occasionally voiced is to invest time in "making [OpenGL] binaries less demanding in regards to the glibc version"¹.

Forgetting about maintenance costs for a moment, one can also see it would benefit downstream applications to start generally tracking each package's lowest compatible glibc - by building against it -, while ensuring that only one version - the newest - is ever referred to in runtime closures. For example, if such a mechanism were in place it would've been "trivial" to use Nix to create "manywheel" releases of python packages.

It would be (?) a reasonable starting point to implement an easy to use stdenvAdapters-like mechanism for separating the lib(std)c(++) used at build time from the one recorded in final RUNPATHs, LD_LIBRARY_PATHs, ld.so.cache-s, etc. We can test such mechanism by first applying it to our impure drivers

EDIT(2024-08-12): Apparently there's also the matter of which ld.so to use:

❯ nix build github:NixOS/nixpkgs/nixos-23.05#hello -o hello2305                         
❯ nix build github:NixOS/nixpkgs/master#glibc.lib -o libc2411                            
❯ nix build github:NixOS/nixpkgs/master#glibc.out -o libc2411                            
❯ nix build github:NixOS/nixpkgs/master#hello -o hello2411                               
❯ nix build github:NixOS/nixpkgs/nixos-23.05#glibc.out -o libc2305
❯ LD_LIBRARY_PATH="$(readlink -f $PWD/libc2305/lib)" LD_DEBUG=libs ./hello2305/bin/hello # Expected success
...
Hello, world!
❯ LD_LIBRARY_PATH="$(readlink -f $PWD/libc2411/lib)" LD_DEBUG=libs ./hello2411/bin/hello # Expected success
...
Hello, world!
❯ LD_LIBRARY_PATH="$(readlink -f $PWD/libc2305/lib)" LD_DEBUG=libs ./hello2411/bin/hello # Expected failure
...
*** stack smashing detected ***: terminated
...
❯ LD_LIBRARY_PATH="$(readlink -f $PWD/libc2411/lib)" LD_DEBUG=libs ./hello2305/bin/hello # Unexpected failure
...
   2943758:     /nix/store/0wydilnf1c9vznywsvxqnaing4wraaxp-glibc-2.39-52/lib/libc.so.6: error: symbol lookup error: undefined symbol: __tunable_is_initialized, version GLIBC_PRIVATE (fatal)
./hello2305/bin/hello: symbol lookup error: /nix/store/0wydilnf1c9vznywsvxqnaing4wraaxp-glibc-2.39-52/lib/libc.so.6: undefined symbol: __tunable_is_initialized, version GLIBC_PRIVATE
❯ LD_LIBRARY_PATH="$(readlink -f $PWD/libc2411/lib)" LD_DEBUG=libs ./libc2411/lib/ld-linux-x86-64.so.2 "$(readlink -f ./hello2305/bin/hello)"
...
Hello, world!

Footnotes

1. https://discourse.nixos.org/t/help-understanding-the-libgl-abi-problem-and-possible-solutions/42022/21 ↩

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/help-understanding-the-libgl-abi-problem-and-possible-solutions/42022/26

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/libc-version-is-different-before-and-after-nix-shell-p/43946/3

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/review-of-333575/50496/2

[kjeremy]

@SomeoneSerge Is there a plan to do this or an outline of the steps needed? I am running into this issue building software against 22.05 (that I cannot easily upgrade) and running on 24.04.