DEV Community: Weifeng Liu

ldd says 'not a dynamic executable' — your static binary is fine

Weifeng Liu — Fri, 13 Nov 2026 23:39:10 +0000

Short answer

ldd reads the dynamic section of an ELF file. A statically linked binary has none,
so ldd reports not a dynamic executable and exits 1. The binary is not broken.
It simply does not need a loader at runtime.

This is the most common false alarm in Linux binary troubleshooting: people read it as
"the executable is invalid" and start looking for a missing library that does not exist.

Confirm it in three commands

Take any static binary — a Go or Rust build, or busybox from a static image — and run:

$ ldd ./hello-static
        not a dynamic executable
$ echo $?
1

$ file ./hello-static
./hello-static: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
statically linked, Go BuildID=rLXBd7VvG-TozsbigJ3a/..., stripped

$ readelf -d ./hello-static
There is no dynamic section in this file.

file says statically linked and readelf -d says no dynamic section. Both agree
with ldd. Nothing is missing.

What the message actually means

Tool	Says	Because
`ldd`	`not a dynamic executable`	no `DT_NEEDED`, no `PT_INTERP`
`file`	`statically linked`	same reason, different wording
`readelf -d`	`There is no dynamic section in this file.`	the `.dynamic` section is absent
`readelf -l \	grep -c INTERP`	`0`

Contrast with a dynamically linked binary on the same host:

$ readelf -l ./hello-new | grep -A1 INTERP
  INTERP         0x0000000000000318 0x0000000000000318 0x0000000000000318
$ readelf -d ./hello-new | grep NEEDED
 0x0000000000000001 (NEEDED)   Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)   Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)   Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)   Shared library: [libc.so.6]

An INTERP entry plus a list of NEEDED libraries is what ldd needs to do its job.
A static binary has neither.

Where this shows up in practice

Go and Rust builds. CGO_ENABLED=0 Go builds and musl-targeted Rust builds are static
by default. Running ldd on them is a category error, not a defect.

Distroless and scratch images. There is no shell, no binutils, sometimes no ldd.

Static busybox. busybox --install links applets into a single static binary; every
applet reports this message.

Jump hosts without binutils. A slim debian:12 image has neither file nor readelf:

$ file ./hello-static
sh: 1: file: not found
$ readelf -h ./hello-static
sh: 1: readelf: not found

That is exactly the situation the ELF Inspector exists for — it
parses in your browser, so the target host needs no tooling and the binary is not uploaded.

When `not a dynamic executable` is a real problem

Rarely, but it matters:

You expected a dynamic binary. If a build system silently produced a static binary, dlopen() will fail at runtime because there is no dynamic loader in the process.
glibc NSS breaks. A fully static glibc binary cannot load NSS modules (getpwnam, DNS via getaddrinfo can behave oddly). Use -static with care, or prefer static musl.
The binary was corrupted mid-transfer. Combined with a truncated file, ldd can also report this. Check the size and a checksum if the file came over the network.

In every other case the message is informational.

What to use instead

# what kind of file is it at all
file ./binary

# architecture, word size, endianness, type
readelf -h ./binary | head -20

# any dynamic dependencies (empty output = static)
readelf -d ./binary | grep NEEDED

# interpreter present?
readelf -l ./binary | grep INTERP

# the same information without installing binutils
# -> open the binary in the browser ELF Inspector

The browser tool reports the same fields and adds the verdicts that are easy to get wrong
by hand: PIE, static vs shared object, full RELRO, stripped, and the required
GLIBC_* / GLIBCXX_* symbol versions.

One safety note about `ldd`

For dynamically linked binaries, ldd is not a pure reader. Most implementations
execute the program's own loader (LD_TRACE_LOADED_OBJECTS) to get the resolution result.
On an untrusted binary that means running its interpreter.

Static binaries are not affected — that is the one case where ldd genuinely cannot
execute anything. For untrusted files, prefer readelf -d or the browser tool, which only
parse data.

FAQ

Does not a dynamic executable mean the binary is corrupted? No. It means there is no
dynamic section to inspect. A corrupted file usually gives a different error
(cannot execute binary file, invalid ELF header).

Why does ldd exit 1 then? Because it could not perform the requested inspection.
Exit status reflects the tool's success, not the binary's validity.

How do I know whether a binary is static or dynamic without ldd? file prints
statically linked or dynamically linked; readelf -d prints the dynamic section or
says there is none.

Can a static binary still fail at runtime? Yes — on a kernel that does not support its
architecture, on a filesystem mounted noexec, or when it needs files it expects to find
(glibc static + NSS). Those are different errors than this one.

glibc and GLIBCXX versions by distribution, measured inside 27 official images

Weifeng Liu — Fri, 13 Nov 2026 23:37:53 +0000

I kept hitting the same two errors on builds that worked a minute earlier:

version `GLIBC_2.34' not found
version `GLIBCXX_3.4.29' not found

The advice everywhere is "copy the library from the machine where it works". I tried
it properly, with a real build, and it fails one layer deeper than you expect. That
sent me looking for an actual table of what each distribution ships — and none
existed, so I measured one.

What I measured

For each release: ldd --version for glibc, and the highest GLIBCXX_* symbol
version inside libstdc++.so.6. Every row came out of the official image, not from
memory. 27 releases, each image removed immediately afterwards.

Distribution	Release	glibc	musl	Highest GLIBCXX
Ubuntu	16.04	2.23	—	3.4.21
Ubuntu	18.04	2.27	—	3.4.25
Ubuntu	20.04	2.31	—	3.4.28
Ubuntu	22.04	2.35	—	3.4.30
Ubuntu	24.04	2.39	—	3.4.33
Ubuntu	25.04	2.41	—	3.4.34
Debian	10	2.28	—	3.4.25
Debian	11	2.31	—	3.4.28
Debian	12	2.36	—	3.4.30
Debian	13	2.41	—	3.4.33
Alpine	3.20	—	1.2.5	—
CentOS	7	2.17	—	3.4.19
Rocky Linux	8 / 9	2.28 / 2.34	—	3.4.25 / 3.4.29
AlmaLinux	8 / 9	2.28 / 2.34	—	3.4.25 / 3.4.29
Amazon Linux	2 / 2023	2.26 / 2.34	—	3.4.24 / 3.4.33
openSUSE Leap	15.6	2.38	—	3.4.34
Arch Linux	rolling	2.44	—	3.4.36

Full 27-row table and the method: readelf.com/guides/glibc-version-by-distribution

The trap nobody mentions

Look at Rocky 9: glibc 2.34, but only GLIBCXX 3.4.29. A C++ binary built on
Ubuntu 22.04 (GLIBCXX 3.4.30) satisfies every glibc requirement there and still
refuses to start. Two independent version gates, and people only check one.

Why copying libstdc++.so.6 does not work

This is the part worth testing rather than repeating. Built on ubuntu:24.04 with
g++ 13.3:

$ ./hello-new
built with 13.3.0

Same binary on debian:12:

$ ./hello-new
./hello-new: libstdc++.so.6: version `GLIBCXX_3.4.32' not found
./hello-new: libstdc++.so.6: version `GLIBCXX_3.4.31' not found

Now copy the newer library across, keeping the SONAME:

$ cp /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33 ./lib/libstdc++.so.6
$ LD_LIBRARY_PATH=./lib ldd ./hello-new | grep stdc++
        libstdc++.so.6 => ./lib/libstdc++.so.6      # the copy IS used

$ LD_LIBRARY_PATH=./lib ./hello-new
./hello-new: libc.so.6: version `GLIBC_2.38' not found
             (required by ./lib/libstdc++.so.6)

The loader picked the bundled library, and it still failed — because that newer
libstdc++ was itself built against glibc 2.38, and Debian 12 has 2.36.

The C++ runtime and the C runtime move as a pair. Pulling one forward drags the
other with it.

What actually works

Build on the oldest image that still compiles your code. One command, no guessing:

   docker run --rm -v "$PWD":/src -w /src debian:10 g++ -O2 -o app app.cpp

Link the C++ runtime statically — removes the GLIBCXX requirement entirely (glibc stays dynamic, so you still need a compatible glibc):

   g++ -O2 -static-libstdc++ -static-libgcc -o app app.cpp

Go fully static against musl when the binary has to run anywhere:

   docker run --rm -v "$PWD":/src -w /src alpine:3.20 \
     sh -c 'apk add --no-cache g++ && g++ -O2 -static -o app app.cpp'

Match the target image if it only ever runs in a container.

Checking a binary without running it

readelf --version-info ./app prints the required symbol versions, and
grep -aoE 'GLIBCXX_3\.4\.[0-9]+' /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | sort -V | tail -1
prints what the host offers. Compare the two and you know before deploying.

I also built a browser-based ELF inspector that reads the same fields without
uploading anything: https://readelf.com/tools/elf-inspector/ — useful on jump
hosts where binutils is not installed (a slim debian:12 image has neither file
nor readelf).

Measured 2026-11-14 on x86-64. Corrections welcome — if a row is wrong for your
distribution, that is a bug and I want to know.