Environment
valkey-glide-rb (gem, installed from RubyGems)
Debian 11 (bullseye), glibc 2.31
Also reproduces on Ubuntu 20.04, glibc 2.31
Problem
bundle install succeeds, but requiring the gem fails at load time:
version `GLIBC_2.38' not found (required by lib/valkey/native/x86_64-unknown-linux-gnu/libglide_ffi.so)
Root cause
The gem ships a prebuilt .so per platform, built in CI. Looking at .github/json_matrices/build-matrix.json and cd.yml, the x86_64-unknown-linux-gnu target is built on ubuntu-24.04, which has glibc 2.39. The resulting binary links against glibc symbols that only exist from 2.38 onward.
glibc backward compatibility only runs one direction — a binary built against an older glibc runs fine on newer systems, but not the reverse. So this binary works on anything ≥2.39, but not on Debian 11 or Ubuntu 20.04, both of which are still glibc 2.31 and still within their support windows.
We confirmed this isn't a problem in the actual Rust/FFI code — building from source on our own machines (rake native:build, which just runs cargo build --release in valkey-glide/ffi) works with no glibc issues at all, because it links against whatever glibc is on the box doing the compiling. The problem is specifically that the CI runner used to produce the published binary has a newer glibc than a lot of currently-supported Linux is running.
Suggested fix
Build the x86_64-unknown-linux-gnu (and aarch64 equivalent) target on an older-glibc runner — something like ubuntu-20.04 or a RHEL8-family image (glibc 2.28, e.g. AlmaLinux 8 / manylinux_2_28) instead of ubuntu-24.04. That would drop the floor low enough to cover Debian 11 / Ubuntu 20.04 without giving up compatibility with newer distros. At minimum, documenting the actual glibc requirement for the published gem would save people the debugging time.
Most of our applications are on ubuntu 20.04 or Debian 11. So, we cannot ask them to directly upgrade to latest version as that might break something else.
Environment
valkey-glide-rb (gem, installed from RubyGems)
Debian 11 (bullseye), glibc 2.31
Also reproduces on Ubuntu 20.04, glibc 2.31
Problem
bundle install succeeds, but requiring the gem fails at load time:
version `GLIBC_2.38' not found (required by lib/valkey/native/x86_64-unknown-linux-gnu/libglide_ffi.so)
Root cause
The gem ships a prebuilt .so per platform, built in CI. Looking at .github/json_matrices/build-matrix.json and cd.yml, the x86_64-unknown-linux-gnu target is built on ubuntu-24.04, which has glibc 2.39. The resulting binary links against glibc symbols that only exist from 2.38 onward.
glibc backward compatibility only runs one direction — a binary built against an older glibc runs fine on newer systems, but not the reverse. So this binary works on anything ≥2.39, but not on Debian 11 or Ubuntu 20.04, both of which are still glibc 2.31 and still within their support windows.
We confirmed this isn't a problem in the actual Rust/FFI code — building from source on our own machines (rake native:build, which just runs cargo build --release in valkey-glide/ffi) works with no glibc issues at all, because it links against whatever glibc is on the box doing the compiling. The problem is specifically that the CI runner used to produce the published binary has a newer glibc than a lot of currently-supported Linux is running.
Suggested fix
Build the x86_64-unknown-linux-gnu (and aarch64 equivalent) target on an older-glibc runner — something like ubuntu-20.04 or a RHEL8-family image (glibc 2.28, e.g. AlmaLinux 8 / manylinux_2_28) instead of ubuntu-24.04. That would drop the floor low enough to cover Debian 11 / Ubuntu 20.04 without giving up compatibility with newer distros. At minimum, documenting the actual glibc requirement for the published gem would save people the debugging time.
Most of our applications are on ubuntu 20.04 or Debian 11. So, we cannot ask them to directly upgrade to latest version as that might break something else.