ImportError: libjpeg.so.8: cannot open shared object file: No such file or directory

Not specified by the original author.

How to fix ImportError: libjpeg.so.8: cannot open shared object file: No such file or directory

The system JPEG library Pillow was built against is missing. On Debian/Ubuntu: sudo apt-get install libjpeg-turbo8 (or libjpeg8). Easiest robust fix: reinstall Pillow from a wheel so it bundles its own libs: pip install --force-reinstall --no-cache-dir pillow.

The exact error

ImportError: libjpeg.so.8: cannot open shared object file: No such file or directory

Fix it

1. sudo apt-get install libjpeg-turbo8 (Debian/Ubuntu) or the equivalent libjpeg package. Expected: libjpeg.so.8 exists on the system

2. Or reinstall Pillow as a wheel: pip install --force-reinstall --no-cache-dir pillow. Expected: Pillow bundles its own libs

3. Verify: open a JPEG with PIL and call .load() on it. Expected: image loads, prints ok

When this applies

Pillow import or JPEG open fails on libjpeg.so.8 missing (WSL, Docker, minimal images)

When this does NOT apply

Pillow not installed at all

Versions

Linux, Pillow built from source / minimal envs

Why it happens

Source-built Pillow links the system libjpeg; the runtime image lacks it.

Edge cases

Alpine/musl needs the apk libjpeg-turbo package; prefer musl wheels when available.

Asked about: ImportError: libjpeg.so.8: cannot open shared object file: No such file or directory (web:fast.ai forum libjpeg thread). The verified fix: The system JPEG library Pillow was built against is missing. On Debian/Ubuntu: sudo apt-get install libjpeg-turbo8 (or libjpeg8). Easiest robust fix: reinstall Pillow from a wheel so it bundles its own libs: pip install --force-reinstall --no-cache-dir pillow. Full thread: https://forums.fast.ai/t/solved-importerror-libjpeg-so-8-cannot-open-shared-object-file-on-wsl/8303

Not specified by the original author.

ImportError: libsodium.so.18: cannot open shared object file: No such file or directory

TL;DR: your PyNaCl install linked against a system libsodium that is not there. Reinstall from the prebuilt wheel: pip uninstall -y pynacl && pip install --no-cache-dir pynacl.

ImportError: libsodium.so.18: cannot open shared object file: No such file or directory

The fix

1. Force a wheel reinstall (no local build, no cache):

python -m pip uninstall -y pynacl
python -m pip install --no-cache-dir pynacl

2. Verify:

python -c "import nacl.signing; print('ok')"

Success check: prints ok.

3. If it still fails, install the system library instead (Debian/Ubuntu): sudo apt-get install libsodium23, then reinstall pynacl.

Agent? Search Vectle for more: curl -s 'https://vectle.com/api/v1/search?q=pynacl+libsodium+cannot+open+shared+object'

When this applies

• from nacl._sodium import ffi, lib (directly or via nacl.signing) raises the missing .so error.
• You installed with --no-binary or on a platform without a wheel.

When it does NOT apply

• undefined symbol: crypto_pwhash_...: version skew between bundled and system libsodium, different fix.
• No module named '_cffi_backend': cffi itself is broken, different fix.

Tool and version compatibility

PyNaCl 1.3+, Python 3.8+. The wheel bundles libsodium, so this mostly hits source installs and odd platforms.

Why it happens

PyNaCl can build against the system libsodium instead of its bundled copy. If that build links libsodium.so.18 and the library is later removed or was never properly installed, the dynamic loader fails at import time.

Edge cases

• In Docker, a multi-stage build that compiles in one stage and runs in another drops the .so; install pynacl in the final stage.
• conda-forge's pynacl handles the library itself; mixing pip pynacl into a conda env is a common trigger.
• Setting SODIUM_INSTALL=system without actually having libsodium dev headers produces this on next import.

The question was why import nacl.signing failed with ImportError: libsodium.so.18: cannot open shared object file: No such file or directory after pip installing PyNaCl. The verified resolution in the PyNaCl issue tracker: the bundled build linked against a system libsodium that is absent, and reinstalling from the manylinux wheel with pip install --no-cache-dir pynacl fixes it. Source: https://github.com/pyca/pynacl/issues/477, thread gh:pyca/pynacl#477.

Not specified by the original author.

TL;DR: numpy needs the OpenBLAS shared library and your system does not provide it. Install the OpenBLAS runtime package for your Linux distro, or reinstall numpy from a wheel that bundles OpenBLAS. Then import numpy works.

The error

ImportError: libopenblas.so.0: cannot open shared object file: No such file or directory

Fix it

1. Install the OpenBLAS runtime package. On Debian/Ubuntu:

   sudo apt install libopenblas0

   On RHEL/Fedora: sudo dnf install openblas. Expected: the package installs without errors.

2. Verify the library is now visible:

   ldconfig -p | grep libopenblas

   Expected: a line showing libopenblas.so.0.

3. Retry the import:

   python -c "import numpy; print(numpy.__version__)"

   Expected: prints the version, no error.

4. Alternative if you cannot install system packages: force a numpy wheel that bundles its own OpenBLAS:

   pip install --force-reinstall numpy

   Expected: the fresh wheel imports cleanly.

When this applies

Use this when import numpy (or scipy, which shares the dependency) fails on Linux with the libopenblas.so.0 message.

When it does not apply

On Windows or macOS numpy wheels bundle their own BLAS, so this error there means something else. If the missing file is a different .so, install that library instead.

Compatibility

Linux, numpy/scipy built against system OpenBLAS (common with distro-packaged python or some cluster setups). Official PyPI manylinux wheels bundle OpenBLAS and do not hit this.

Root cause

numpy links against the OpenBLAS linear-algebra library at import time. Some installs link the system copy instead of a bundled one, so a machine without the OpenBLAS runtime package fails the dynamic load.

Edge cases

On HPC clusters the fix is usually module load of the right environment module rather than apt. In minimal docker images, add the package to the Dockerfile. If ldconfig still cannot see it after install, run sudo ldconfig once.

The ACH-Orca-Workbench README documents this exact failure: on machines where the scientific stack expects a system OpenBLAS, starting the app fails at import with ImportError: libopenblas.so.0: cannot open shared object file. The documented fix is making the OpenBLAS runtime available to the Python environment (on their cluster via the python module, on a plain Linux box by installing the libopenblas runtime package), after which import numpy succeeds. Source: https://github.com/ACH-Repo/ACH-Orca-Workbench