I decided to try my hand at packaging the latest Zrythm alpha (1.0.0.alpha.25.1.22) based on the latest draft PR, which is currently stalled at 1.0.0-alpha.19.0.1. This is my story:
Attempt 1: Add the new deps and update the Meson flags as needed. Result: The build failed. The log shows a few plugin needed to handle lto object messages followed by hundreds of linker errors citing undefined references to internal functions.
Attempt 2: Force the use of lld and other llvm tools for LTO. (I followed the Firefox impl for this.) Result: The build succeeded (only with buildPackages.llvmPackages_10). However, the binary fails on execution with the following output:
/nix/store/hashredacted-zrythm-1.0.0.alpha.25.1.22/bin/zrythm: /nix/store/hashredacted-glibc-2.32-54/lib/libc.so.6: version `GLIBC_2.33' not found (required by /nix/store/hashredacted-libaudec-0.3.4/lib/libaudec.so)
This is the same error discussed in this thread, but in my case, I didn’t update any channels.
Attempt 3: Wrap the audec binary (and the zrythm binary, just in case) to set LD_PRELOAD to the libredirect library and NIX_REDIRECTS to redirect the glibc 2.32 call to glibc 2.33. (I tried this after reading @jonringer’s advice in the thread linked above, but in case it’s not obvious, I’m basically cargo culting lines grepped from other packages at this point. ) Result: No change.
I’m relatively new to this space, so any ideas or pointers would be much appreciated. Thanks!
Some data points:
NixOS 21.05.20211003.8df64b0, built from flake
System-installed ldd (GNU libc) 2.33
Interpreter for Zrythm binary (/nix/store/hashredacted-zrythm-1.0.0.alpha.25.1.22/bin/zrythm): /nix/store/hashredacted-glibc-2.32-54/lib/ld-linux-x86-64.so.2
Interpreter for libaudec binary (/nix/store/hashredacted-libaudec-0.3.4/bin/audec): /nix/store/hashredacted-glibc-2.33-50/lib/ld-linux-x86-64.so.2
Interesting to see this come up again now of all times.
I am the original author of the thread you mentioned. My version of this problem was magically fixed after I updated my system channels again and rebooted.
However it recently (yesterday) came up again for me in some seemingly unrelated place, while updating a remote machine using nixos-rebuild --target-host.
I am also still very much in the cargo-cult zone of nixos adoption, so I have no real clue as to whats happening here. Some package requires glibc 2.33, right? So shouldn’t the package manager just fetch that version of the lib and be done with it? Even if other parts of the system require another version, as far as I have understood it it will just get both if both are required simultaneously, right?
As I understand it, by default, Nix defers to the specified channel to determine which package revisions (thus which versions/commits of programs) to use to build a given derivation. I believe the assumption is that (unless marked as broken, etc.) all packages included in a given stable channel revision are compatible (i.e., will successfully compile) with their respective dependent packages. Some programs merit separate packages for different versions (e.g., python37, python38, etc.), and while there are a few packages for glibc, they all point to the same version per channel.
With that said, I’ve clearly gotten my wires crossed somewhere.
What presently baffles me in the curious case of Zrythm is that the binary of the program I’m trying to package (zrythm) is compiled with a different interpreter version from that of its dependency (audec):
zrythm uses glibc 2.32, which is what I would expect because the host is following the 21.05 stable branch (which is currently on glibc 2.32-54).
audec unexpectedly uses glibc 2.33, which is the current version on the unstable channel.
I’m further baffled by the fact that despite following the stable channel, installing bintools gives me ldd (GNU libc) 2.33. @busti If I may ask, which channel are you following?
)