Glibc 2.33 vs 2.34 Rust Madness

Help
1

We are building Rust software in nix-shell. Our Rust is from nixpkgs-unstable. Recently nixpkgs-unstable seems to have switched to glibc 2.34, which causes sadness if the underlying system is using glibc 2.33 (like NixOS 21.11 or Ubuntu). This results in errors like these:

error: /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libpthread.so.0: undefined symbol: __libc_siglongjmp, version GLIBC_PRIVATE
   --> /home/julian/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro-error-1.0.4/src/lib.rs:284:9
    |
284 | pub use proc_macro_error_attr::proc_macro_error;
    |         ^^^^^^^^^^^^^^^^^^^^^

or

error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /home/peter/Development/particle/ws/target/debug/deps/libproc_macro_error_attr-fab057cc0610f574.so)
   --> /home/snuernberger/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro-error-1.0.4/src/lib.rs:284:9
    |
284 | pub use proc_macro_error_attr::proc_macro_error;
    |         ^^^^^^^^^^^^^^^^^^^^^

If we use nix-shell --pure and clean up all ~/.cargo and target folders, things work, but this is a pretty drastic solution. Most of us want to leak some things from the environment into their nix-shell for productivity.

2 Likes
2

have you considered just using fenix? It’s a lot easier to keep up with the latest rust releases and I’ve never had any issues like this. It’s pretty convenient to ensure that the exact rust toolchain used by your project is always available directly from your shell.

1 Like
3

You can export LD_PRELOAD to force the use of the nixpkgs glibc everywhere in the shell.

4

Related, perhaps: github-runner impure environment · Issue #169812 · NixOS/nixpkgs · GitHub

5

I’ve had this exact problem while using fenix - and the problem goes away without it. So I don’t think switching to it is the right suggestion.

I’m actually quite unclear why this happens with flakes - aren’t they supposed to be hermetic? What is leaking from the host’s environment?

6

I stand corrected on my comment above: it was not the usage of fenix that caused the issue, but the fact that I mixed two different versions of nixpkgs: one was the pinned nixpkgs input in the flake (fenix.inputs.nixpkgs), the other passed into the a derivation as the pkgs argument. Turns out that those brought in two different versions of glibc, which caused the problem.