Fix "libc.so.6: version 'GLIBC_2.xx' not found"

ldd --version | head -1
objdump -T ./myapp | grep -o 'GLIBC_[0-9.]*' | sort -uV | tail -1

What the error means

$ ./myapp
./myapp: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by ./myapp)
./myapp: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.39' not found (required by ./myapp)

glibc, the GNU C library, provides the basic functions nearly every program uses. Its symbols are versioned: when glibc adds or changes a function, the new version gets a tag such as GLIBC_2.38. A program built against glibc 2.39 records that it needs those tags. Your system's libc.so.6 is older and does not have them, so the loader refuses to start the program.

glibc is backward compatible but not forward compatible: old programs run on new systems, new programs do not run on old ones. On Fedora, openSUSE and RHEL-family systems the path reads /lib64/libc.so.6; on Arch, /usr/lib/libc.so.6. The meaning is identical.

The C++ equivalent looks like this and has the same cause:

./myapp: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by ./myapp)

Find the gap

# your glibc
ldd --version | head -1
# the highest glibc tag the binary needs
objdump -T ./myapp | grep -o 'GLIBC_[0-9.]*' | sort -uV | tail -1
# for C++ programs
strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep -o 'GLIBCXX_[0-9.]*' | sort -uV | tail -1

Reference points for common releases (confirm on your machine with ldd --version):

So a binary built on Ubuntu 24.04 (2.39) will typically fail on Ubuntu 22.04 (2.35) or Debian 12 (2.36) with exactly this error.

Fix 1: get a build that matches your system (best)

• Use the distro package (apt, dnf, pacman, zypper). It is built against your glibc by definition.
• Download a different build: many projects publish a musl or fully static variant (common for Go and Rust tools) that does not depend on the system glibc, or a build labelled for an older baseline such as "glibc 2.28" or "manylinux2014".
• Use Flatpak, Snap or AppImage: Flatpak and Snap ship their own runtime with its own glibc. AppImages are built on old bases on purpose, but a carelessly built one can still hit this error.
• Build from source on your machine; the result links against your glibc.

Python users see this as a failing import from a binary wheel. Upgrading pip lets it choose wheels tagged for your glibc (manylinux) instead of forcing a source build.

Fix 2: run it in a container with a newer userland

A container brings its own glibc while sharing your kernel, so a program built for Ubuntu 26.04 runs fine inside an Ubuntu 26.04 container on an older host. Distrobox makes this nearly transparent, sharing your home directory and display:

distrobox create --name new --image ubuntu:26.04
distrobox enter new
./myapp

Plain Docker or Podman works too:

podman run --rm -it -v "$PWD":/work -w /work ubuntu:26.04 ./myapp

See the Docker guide for installing a container runtime.

Fix 3: upgrade your distribution

If you run old releases and keep meeting this error, the clean fix is a release upgrade, which brings a newer glibc that every package on the system has been built against. Ubuntu 22.04 is supported only until April 2027, so moving to 24.04 or 26.04 is due anyway: see upgrading Ubuntu, or upgrading Debian and upgrading Fedora. The release cycle guide shows how long each release is supported.

What not to do

If you really need a newer glibc on an old system for one program, build it into a separate prefix such as /opt/glibc-2.39 and start the program with that prefix's loader (/opt/glibc-2.39/lib/ld-linux-x86-64.so.2 --library-path /opt/glibc-2.39/lib:/usr/lib/x86_64-linux-gnu ./myapp). This is fragile and only worth it when containers are not an option.

Distro-specific notes

• Ubuntu, Debian, Mint: glibc is the libc6 package; apt policy libc6 shows the installed version. Mint 22.x shares Ubuntu 24.04's glibc.
• Fedora: glibc is the glibc package (rpm -q glibc). Fedora moves fast, so binaries built on Fedora often fail on Debian stable or RHEL; build on the oldest system you need to support.
• Arch and openSUSE Tumbleweed: rolling releases always have a recent glibc, so this error there usually means you skipped updates. Run sudo pacman -Syu or sudo zypper dup.
• Remote tools: editors' remote-server components and prebuilt CLIs often state a minimum glibc; older servers such as RHEL 7 or Ubuntu 18.04 fall below it.

How to prevent it

• When you ship binaries, build on the oldest distro you support (or in a manylinux / old-distro container), or link statically with musl.
• Prefer packaged software, Flatpak or containers over binaries copied from another machine.
• Keep systems on a supported release; if the library is missing entirely rather than too old, see "error while loading shared libraries".

Frequently asked questions