Fix ImportError: libcublas.so.9.0 cannot open shared object file

ImportError: libcublas.so.9.0: cannot open shared object file: No such file or directory is a dynamic-linking failure. When your framework (usually TensorFlow-GPU, sometimes PyTorch) loads, the OS linker tries to open the exact CUDA library it was built against — libcublas.so.9.0 — and can't find it on the search path. The same pattern covers libcudart.so.11.0, libcudnn.so.7, libcufft.so.10, and every other lib*.so.<version> CUDA error: same cause, same fix.

Why the version suffix matters

That .9.0 is a SONAME — the exact major.minor the binary was compiled to link. cuBLAS from CUDA 9.0 is libcublas.so.9.0; from CUDA 11 it's libcublas.so.11. They are different files, and the loader will not accept one for the other. So "I have CUDA installed" isn't enough — you need the specific version your framework build expects. A request for libcublas.so.9.0 means something on your machine (a TensorFlow build for CUDA 9.0) needs CUDA 9.0, and 9.0 either isn't installed or isn't on the path.

Triage in one command

ldconfig -p | grep libcublas

• It prints a path → the library exists; this is a path problem. The loader just doesn't know where it is.
• It prints nothing → the library isn't installed. This is a missing-toolkit problem.

Confirm what versions you actually have:

nvidia-smi              # driver + the MAX CUDA it supports
nvcc --version          # the installed CUDA TOOLKIT version
find / -name 'libcublas.so*' 2>/dev/null   # where any cuBLAS lives

Remember: nvidia-smi's CUDA number is the driver's ceiling, not the installed toolkit. The framework needs the toolkit libraries present.

Fix 1 — path problem: point the loader at the library

If libcublas.so.9.0 exists (say under /usr/local/cuda-9.0/lib64) but isn't found, add its directory to the loader path:

export LD_LIBRARY_PATH=/usr/local/cuda-9.0/lib64:$LD_LIBRARY_PATH
sudo ldconfig            # refresh the loader cache

Persist it by adding a file under /etc/ld.so.conf.d/ (then sudo ldconfig) or exporting LD_LIBRARY_PATH in your shell profile / service env.

Fix 2 — missing toolkit: install the matching CUDA

If it isn't installed, install the CUDA version your framework wants (9.0 here), plus the matching cuDNN. The versions must line up with the framework's compatibility matrix — each TensorFlow release targets a specific CUDA + cuDNN pair. Installing CUDA 11 will not satisfy a libcublas.so.9.0 request.

Fix 3 — the clean way: let a tool match the stack

Hand-managing CUDA .so files is where hours disappear. Two approaches remove the problem:

# conda pulls a compatible cudatoolkit + cudnn automatically
conda install -c conda-forge tensorflow-gpu=1.12
 
# or run the official GPU image; only the host NVIDIA driver is needed
docker run --gpus all -it tensorflow/tensorflow:2.15.0-gpu bash

Both give you a framework whose CUDA libraries are guaranteed to match.

Fix 4 — or move the framework to your CUDA

If you're stuck on a specific CUDA version, install a framework build compiled for it instead. Matching either direction works — the point is that the framework's expected CUDA and the installed CUDA must be the same major.minor.

Prevent it

• Match versions deliberately using the framework's CUDA/cuDNN compatibility table before installing.
• Prefer conda or Docker so the GPU stack is resolved for you.
• Keep driver and toolkit straight: the driver sets the ceiling; the toolkit provides the libraries the framework links.
• Pin everything in a reproducible environment file so the matched stack doesn't drift.

Decide whether it's a path or a missing-library problem with one ldconfig command, then either expose the existing library or install the exact CUDA version your framework was built against.

Sources

• TensorFlow API docs