Introduction

The error ImportError: libcusolver.so.8.0: cannot open shared object file means a Python package was compiled against a CUDA runtime that your machine cannot provide. In practice, this is almost always a version mismatch between the installed framework and the installed NVIDIA CUDA libraries.

What libcusolver.so.8.0 Actually Tells You

libcusolver is part of NVIDIA CUDA. The 8.0 suffix is important because it points to a specific major runtime version expected by the binary you are importing. If TensorFlow, PyTorch, or another GPU-enabled package asks for libcusolver.so.8.0, then the loader is looking for CUDA 8 era libraries.

That does not necessarily mean your GPU is broken. It usually means one of these situations applies:

• you installed a framework wheel built for an older CUDA version
• CUDA is installed, but the dynamic linker cannot find it
• you mixed packages from different environments or channels
• the machine only has CPU support, but you installed a GPU wheel

Start by checking what the system can currently see:

nvidia-smi
nvcc --version
ldconfig -p | grep libcusolver

If nvidia-smi works but ldconfig shows no matching libcusolver, the driver is present but the requested runtime library is not available in the loader path.

Fix the Version Mismatch First

The clean fix is to align the framework with the CUDA version it expects. Avoid random symlinks between incompatible versions. A fake libcusolver.so.8.0 symlink pointing to a newer library may suppress the import error and then fail later with symbol mismatches.

For example, if an older TensorFlow build expects CUDA 8, install the version pair documented for that build, or switch to a newer TensorFlow release that matches the CUDA runtime you already have.

In a Python virtual environment, reinstalling the package cleanly often solves the issue:

1python -m venv .venv
2source .venv/bin/activate
3pip install --upgrade pip
4pip install tensorflow

If you specifically need a GPU build tied to an older CUDA stack, use a dedicated environment rather than mixing it with current packages.

Check the Library Search Path

Sometimes the correct library exists, but Linux cannot locate it. Typical CUDA installations place libraries under directories such as /usr/local/cuda/lib64.

Inspect the filesystem directly:

find /usr/local -name 'libcusolver.so*' 2>/dev/null

If the expected file exists, make sure the linker knows where to look:

export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH
python -c "import tensorflow"

For a more permanent configuration on Linux, add the CUDA library directory through the dynamic linker configuration and run ldconfig as root.

Prefer Supported Install Paths

Modern Python ML stacks often bundle or coordinate the necessary CUDA pieces through official packaging. That is safer than manually assembling driver, toolkit, cuDNN, and framework versions from unrelated guides.

For PyTorch, the official install selector tells you which package variant matches which CUDA release. For TensorFlow, recent releases have shifted packaging strategies over time, so the correct answer depends on the exact version you are installing. The principle is stable: install a package build that explicitly matches your CUDA runtime.

If you do not need GPU acceleration, the simplest resolution is often to install the CPU build and remove the GPU dependency entirely.

Minimal Diagnostic Workflow

A disciplined troubleshooting sequence saves time:

1python - <<'PY'
2import sys
3print(sys.version)
4try:
5    import tensorflow as tf
6    print(tf.__version__)
7except Exception as exc:
8    print(type(exc).__name__, exc)
9PY

Then compare the framework version with the vendor compatibility matrix, confirm the installed CUDA libraries, and rebuild the environment if the pieces do not line up.

Containers are also useful here. A Docker image that already pins Python, framework, CUDA, and cuDNN versions removes most of the host-level ambiguity.

Common Pitfalls

The biggest mistake is treating the missing library name as an isolated file problem. It is usually an ecosystem compatibility problem, not just a missing file on disk.

Another common mistake is adding broad LD_LIBRARY_PATH values from several CUDA installations. That can make imports non-deterministic, especially when different environments expose different major versions of the same library.

People also waste time trying to fix the issue inside Python only. This error originates in the system dynamic loader, so you need to inspect the OS-level CUDA installation as well.

Summary

• 'libcusolver.so.8.0 indicates a package expects a specific CUDA runtime version.'
• The usual root cause is a mismatch between the installed framework and installed CUDA libraries.
• Check driver visibility, CUDA version, and linker visibility with nvidia-smi, nvcc, and ldconfig.
• Do not rely on version-skipping symlinks as a real fix.
• The clean solution is to install a framework build that matches your CUDA stack, or switch to a CPU-only environment.