ImportError: libGL.so.1: cannot open shared object file: No such file or directory

Not specified by the original author.

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

You are on a headless box and opencv-python wants GUI system libs. Two fixes: install the lib (sudo apt-get install libgl1, often plus libglib2.0-0), or switch to the headless wheel: pip install opencv-python-headless. The headless wheel is the right call for servers and Docker; it has no GUI deps at all.

The exact error

ImportError: libGL.so.1: cannot open shared object file: No such file or directory

Fix it

1. Headless route (recommended): pip uninstall -y opencv-python && pip install opencv-python-headless. Expected: import cv2 works

2. Or install system libs: sudo apt-get install -y libgl1 libglib2.0-0. Expected: import cv2 works with the GUI wheel

3. Docker: add the apt line to your Dockerfile before pip install. Expected: container imports cv2 cleanly

When this applies

import cv2 fails on libGL.so.1 (or libgthread) in Docker/CI/headless Linux

When this does NOT apply

you actually need cv2.imshow (then install the libs, do not go headless)

Versions

Linux Docker / headless servers, opencv-python

Why it happens

opencv-python links Qt/OpenGL system libraries that slim images do not ship.

Edge cases

Never install both opencv-python and opencv-python-headless; they conflict.

Asked about: ImportError: libGL.so.1: cannot open shared object file: No such file or directory (gh:stabrise/scaledp#93). The verified fix: You are on a headless box and opencv-python wants GUI system libs. Two fixes: install the lib (sudo apt-get install libgl1, often plus libglib2.0-0), or switch to the headless wheel: pip install opencv-python-headless. The headless wheel is the right call for servers and Docker; it has no GUI deps at all. Full thread: https://github.com/stabrise/scaledp/issues/93

Not specified by the original author.

TL;DR: Install the NVIDIA driver (libcuda.so.1 ships with the driver, not the CUDA toolkit) or run CPU-only TensorFlow. This error means the machine has no NVIDIA driver, so the GPU build of TF cannot load. If you do not need the GPU, pip install tensorflow-cpu sidesteps the whole thing.

The error:

ImportError: libcuda.so.1: cannot open shared object file: No such file or directory

Fix

1. Run nvidia-smi Expected: if it errors, there is no NVIDIA driver on this machine

2. If you need GPU: install the NVIDIA driver for your OS, then reinstall the matching TF + CUDA/cuDNN per TF's tested build table Expected: import tensorflow loads and tf.config.list_physical_devices('GPU') lists your card

3. If you do not need GPU: pip install tensorflow-cpu Expected: import works, no libcuda complaint

When this applies

• import tensorflow fails naming libcuda.so.1
• running on a machine without an NVIDIA GPU/driver

When this does not apply

• libcudart/libcublas errors (toolkit libs, different fix)
• tensorflow not installed at all

Version compatibility

tensorflow 2.x GPU builds on Linux. libcuda.so.1 comes from the NVIDIA kernel driver package.

Why it happens

TensorFlow's GPU build dlopens libcuda.so.1 at import. That file is installed by the NVIDIA driver, not by pip and not by the CUDA toolkit. No driver, no file, import fails.

Edge cases

• Docker users: use the nvidia-container-toolkit and --gpus all, the host driver must exist.
• WSL2 needs the NVIDIA WSL driver on the Windows side.
• Do not fix this by copying libcuda.so.1 from another machine; install the driver.

Real GitHub issue: ImportError: libcuda.so.1 (gh:windj007/docker-jupyter-keras-tools#6). The issue reports the import failure "ImportError: libcuda.so.1: cannot open shared object file: No such file or directory" and the thread contains the verified resolution used in this skill. Source: https://github.com/windj007/docker-jupyter-keras-tools/issues/6

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