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

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

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.

How to fix OSError: libcudart.so.11.0: cannot open shared object file: No such file or directory

Your torch build wants CUDA 11.0 but the loader cannot find its libraries. Either install the matching CUDA toolkit (or set LDLIBRARYPATH to its lib64 dir), or switch to the CPU-only torch wheel if you do not need the GPU. The version in the filename must match the CUDA your torch was built against.

The exact error

OSError: libcudart.so.11.0: cannot open shared object file: No such file or directory

Fix it

1. Check what CUDA your torch expects: look at the +cuXX tag in python -m pip show torch. Expected: e.g. cu110, cu118, cu121

2. Option A (keep GPU): install that CUDA toolkit, or point the loader at it: export LD_LIBRARY_PATH=/usr/local/cuda-11.0/lib64:$LD_LIBRARY_PATH. Expected: import torch no longer raises the OSError

3. Option B (no GPU needed): pip install torch --index-url https://download.pytorch.org/whl/cpu. Expected: torch imports and runs on CPU

When this applies

import torch (or torchvision/torchgeometric) fails with libcudart.so.X / libcudnn / `libtorchcuda` not found on Linux

When this does NOT apply

Windows DLL errors or No module named 'torch'

Versions

Linux, CUDA builds of torch

Why it happens

CUDA torch wheels still resolve some CUDA libs from the system; a version mismatch or missing toolkit breaks the load.

Edge cases

nvidia-smi showing CUDA 12.x does not mean the toolkit is installed; the driver version and toolkit version are different things.

Asked about: OSError: libcudart.so.11.0: cannot open shared object file: No such file or directory (web:iopenv torch dependency notes). The verified fix: Your torch build wants CUDA 11.0 but the loader cannot find its libraries. Either install the matching CUDA toolkit (or set LDLIBRARYPATH to its lib64 dir), or switch to the CPU-only torch wheel if you do not need the GPU. The version in the filename must match the CUDA your torch was built against. Full thread: https://www.iopenv.com/36E4IQF8I/Program-Error-Torch-Torch-Geometric-Torch-Dependency-issues-with-versions-such-as-sparse