Serde+derive no longer compiles with glibc 3.38

tools and infrastructure cargo
1

Trying to compile serde with the derive feature enabled results in the following error:

   Compiling proc-macro2 v1.0.94
   Compiling unicode-ident v1.0.0
   Compiling ryu v1.0.0
   Compiling serde v1.0.199
   Compiling memchr v2.0.0
   Compiling anyhow v1.0.97
   Compiling csv-core v0.1.11
   Compiling itoa v1.0.0
   Compiling quote v1.0.40
   Compiling syn v2.0.100
   Compiling serde_derive v1.0.199
error: $HOME/src/rs/REDACTED/target/debug/deps/libserde_derive-1b53e5e9a46ff80e.so: /nix/store/p9ysh5rk109gyjj3cn6jr54znvvlahfl-glibc-2.38-66/lib/libc.so.6: version `GLIBC_2.39' not found (required by $HOME/src/rs/REDACTED/target/debug/deps/libserde_derive-1b53e5e9a46ff80e.so)
   --> $HOME/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/serde-1.0.199/src/lib.rs:329:1
    |
329 | extern crate serde_derive;
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^

error: could not compile `serde` (lib) due to 1 previous error

The weird part is that neither rolling back serde or rustc's version fixes this, and the only thing I can think of is me clearing cargo's cache, or that I didn't roll back far enough.

Also, I didn't see an announcment that glibc 3.38 is no longer supported, and it's really not that old, so I'm not sure if this is intentional.

In any case, I'll be doing a system update to glibc 3.40, which hopefully will fix this.

2

(You might get better help on users.rust-lang.org for this question.)

This looks like target/debug/deps/libserde_derive-1b53e5e9a46ff80e.so was originally compiled against glibc 2.39[1] but now cargo is trying to dynamically link it against glibc 2.38. I would try, in this order:

  1. rm -rf target && cargo build
  2. rm Cargo.lock && rm -rf target && cargo build
  3. Clear Cargo's cache, then repeat step 2
  4. Update Nix, reboot, update your personal and/or project Nix profiles, run a Nix garbage collection, then repeat step 3

  1. there is no glibc v3.x and it is the intention of the glibc developers that there never will be ↩ī¸Ž

3

Tried everything except a GC (which shouldn't affect anything), still nothing.

I opened this here because it smells like a bug.

4

SOLVED: I was using clang+mold as my linker, and for some reason that broke this.

1 Like
5

I believe that means this is a bug, but not in Rust; in the Nix packaging of clang+mold, most likely. (Nix has to be involved somehow, because the error messages you quote specifically refer to /nix/store/p9ysh5rk109gyjj3cn6jr54znvvlahfl-glibc-2.38-66/lib/libc.so.6. It is almost certainly Nix's fault that that's referring to glibc-2.38 instead of glibc-2.39.)

2 Likes