glibc_2.34 Not Found Error: 5 Proven Fixes for Ubuntu 20.04 & 22.04

---

The “version `glibc_2.34′ not found” error appears when you try to run a program that was compiled against glibc ≥ 2.34 on a system whose installed glibc is older (Ubuntu 20.04 ships 2.31, Ubuntu 22.04 ships 2.35).
Below you’ll find five battle-tested ways to solve it—without breaking your OS.

---

1. Understand the Problem in 30 s

1. Check your host versionbashCopyldd --version | head -n1Ubuntu 20.04 ➜ ldd (Ubuntu GLIBC 2.31-0ubuntu9.x) 2.31
   Ubuntu 22.04 ➜ ldd (Ubuntu GLIBC 2.35-0ubuntu1.x) 2.35
2. Check what the binary wantsbashCopystrings yourApp | grep GLIBC_2.3If you see GLIBC_2.34 or 2.35, the binary was built on a newer distro.

Table

Copy

Distro	glibc	Safe for 2.34 binary?
18.04	2.27	❌
20.04	2.31	❌
21.10	2.34	✅
22.04	2.35	✅

---

2. Fix 1 – Upgrade Ubuntu (Fastest, Permanent)

Recommended if you’re not tied to 20.04 LTS.

sudo do-release-upgrade -d   # -d only needed before .1 LTS point-release

Upgrading to 22.04 LTS gives you glibc 2.35, satisfying any binary asking for 2.34.
Always back-up /etc, /home and database data first.
Works for WSL as well: wsl --update && wsl --shutdown then sudo do-release-upgrade inside distro

---

3. Fix 2 – Run Inside an Ubuntu 22.04 Container (Zero Risk to Host)

Keep your 20.04 host untouched, but run the app in a 22.04 user-space.

# install Docker if you don’t have it
sudo apt update && sudo apt install docker.io
sudo usermod -aG docker $USER && newgrp docker

# pull 22.04 image
docker run -it --rm -v $PWD:/work -w /work ubuntu:22.04 bash
# inside container
apt update && apt -y install your-libs-here
./yourApp

No glibc conflicts—container uses host kernel but own libc

---

4. Fix 3 – Static-Link When YOU Compile (Developer Solution)

If you build the code, tell GCC to bundle libc instead of asking for the system one.

# Ubuntu 22.04 build machine
sudo apt install gcc make libc6-dev
gcc -static -o mytool mytool.c

The resulting binary is larger but runs anywhere ≥ 2.17, including 20.04

---

5. Fix 4 – Use a Toolchain PPA (Experts Only)

You can safely install a parallel glibc 2.34 from the Ubuntu-toolchain/test PPA without overwriting the system one—but you must invoke the binary with a custom loader path.

sudo add-apt-repository ppa:ubuntu-toolchain-r/test -y
sudo apt update
sudo apt install -y libc6-2.34-dev libc6-2.34

Now run the app with the new loader:

/usr/lib/x86_64-linux-gnu/ld-2.34.so \
  --library-path /usr/lib/x86_64-linux-gnu-2.34 \
  ./yourApp

⚠️ Never replace /lib/x86_64-linux-gnu/libc.so.6 manually; it will brick apt, sudo, even reboot

---

6. Fix 5 – Re-Compile on the Oldest System You Support (Best Practice)

Build on	Runs on	Example CI image
20.04	20.04+	ubuntu-20.04
18.04	18.04+	ubuntu-18.04

GitHub Actions snippet:

jobs:
  build:
    runs-on: ubuntu-20.04
    steps:
      - uses: actions/checkout@v4
      - run: sudo apt -y install build-essential
      - run: gcc -o app src/*.c
      - uses: actions/upload-artifact@v4
        with:
          name: linux-binary
          path: app

This guarantees the ELF doesn’t request anything newer than 2.31

---

7. Checklist – Which Fix Should I Use?

Scenario	Recommended Fix
Personal laptop, can upgrade	Fix 1 (upgrade)
Production server, must stay on 20.04	Fix 2 (container)
Developer, control source	Fix 4 or 5 (static or rebuild)
Need newest GCC but host is 20.04	Fix 4 (toolchain PPA)

---

8. Quick Troubleshooting FAQ

Q1.sudo apt install libc6 says “already newest” but error persists?
A. Your repo only has 2.31 for 20.04—that’s expected. Use Fix 2, 3, or 5.

Q2. Will dpkg -i libc6_2.34*.deb work?
A.NO—it breaks core packages (fakeroot, apt, sudo) and leaves the system un-bootable

Q3. Can I just symlink the new version?
A.NEVER—glibc uses symbol versioning; a simple symlink will seg-fault every command.

---

9. One-Minute Verifier

After applying any fix:

ldd yourApp | grep -E "libc\.so\.6|not found"

No output ➜ success.
Still shows GLIBC_2.34 not found ➜ try the next fix.

---

10. Bottom Line

• Ubuntu 20.04 cannot satisfy glibc ≥ 2.34 natively—full stop.
• Safest paths: upgrade distro, containerize, or re-compile.
• Never manually overwrite system libc—recovery becomes a live-USB nightmare.

Pick the fix that matches your risk tolerance and time budget, and you’ll be running the stubborn binary in minutes—without turning your box into a paperweight.