Which Linux distributions can run this binary?
Drop a binary in. It reads the required GLIBC_* and
GLIBCXX_* symbol versions out of .gnu.version_r and tells you
which of the 27 measured distributions can actually start it — and for the ones that
cannot, exactly which gate fails.
Why this is not just “check the glibc version”
Two independent version tracks decide whether a binary runs. A binary links against symbol versions, not symbol names, and the two gates move separately:
| Gate | Provided by | Example failure |
|---|---|---|
GLIBC_* | libc.so.6 |
version `GLIBC_2.38' not found |
GLIBCXX_* | libstdc++.so.6 |
version `GLIBCXX_3.4.32' not found |
The trap is that a distribution can be new in one and old in the other. Rocky Linux 9 ships glibc 2.34 but only GLIBCXX 3.4.29, so a C++ binary built on Ubuntu 22.04 satisfies every glibc requirement there and still refuses to start. Checking one number is how people lose an afternoon.
What the verdicts mean
| Verdict | Meaning |
|---|---|
| works | Both gates satisfied for every required symbol version |
| glibc too old | The host's libc.so.6 lacks a required symbol version |
| GLIBCXX too old | The C++ runtime is older than the binary needs — rebuild with -static-libstdc++ or on an older image |
| ships musl | Alpine has no glibc at all; a glibc binary cannot run there regardless of version |
| none | No family member satisfies the requirements |
Static binaries
A statically linked binary carries no symbol version requirements, so the answer is
“any host with a matching architecture”. Go builds with CGO_ENABLED=0 and
Rust builds against musl land here. That is also why ldd says
not a dynamic executable
on them — nothing is broken.
How the matrix was measured
Every row comes from running the real image, not from a wiki: ldd --version
for glibc, the musl loader for musl, and the highest GLIBCXX_* string inside
libstdc++.so.6. 27 releases on x86-64, each image removed afterwards.
The full table and method are in
glibc and libstdc++ versions by distribution,
and the collector is public at
github.com/luckyray/glibc-matrix.
FAQ
Does this work for 32-bit binaries? Yes — both ELF classes are parsed, but the matrix is x86-64, so a 32-bit binary's verdicts assume an i386-compatible host.
What about aarch64? The version numbers transfer, but the matrix rows were measured on x86-64 images. Use the verdicts as a starting point, then confirm on the real target.
Is the file uploaded? No. The parser runs in this tab; there is no server-side component to send it to. You can verify in the Network tab of your devtools.
What if it says “no version requirements found”? Either the binary is static, or it was built without symbol versioning. It will start on any host with a compatible architecture, but may still fail for other reasons (missing files, noexec mount, wrong kernel feature).