error while loading shared libraries: libgomp.so.1: cannot open shared object file

Not specified by the original author.

Short answer: install the OpenMP runtime from your OS package manager. On Debian/Ubuntu that is the libgomp1 package; pip cannot fix this one because the missing piece is a system library, not a Python package. `` error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory 1. Confirm the diagnosis: ldconfig -p | grep libgomp returns nothing, and ldd on the failing package's native library (for Python packages, the .so inside site-packages) shows libgomp.so.1 as not found. Expected: both checks agree the runtime is absent. 2. Install it for your platform. Debian/Ubuntu: sudo apt-get update && sudo apt-get install -y libgomp1. RHEL/Fedora family: sudo dnf install -y libgomp. Alpine: apk add libgomp. macOS uses a different runtime name: brew install libomp. Expected: ldconfig -p | grep libgomp` now lists libgomp.so.1. 3. Re-run the import or program. Expected: it loads with no loader error. In Python, verify with a plain import of the package that failed. 4. In Docker, add the install to the Dockerfile (apt-get install libgomp1 in the runtime stage, not just the build stage) and rebuild. Expected: a fresh container from the image imports cleanly; a fix applied by hand inside a running container disappears on restart. Root cause: OpenMP-enabled binaries declare libgomp.so.1 as a needed library, and the dynamic linker resolves needed libraries only from system paths. Distroless and slim base images omit compiler runtimes, so the dependency that the wheel author assumed would always be there is missing. When to use: Linux or container environments where a native or Python ML/scientific package fails at load time with this error. When NOT to use: if libgomp is installed but the error names a version symbol (for example GOMP_4.5 not found), the installed runtime is too old for the binary; upgrade the runtime or use a newer base image rather than reinstalling the same package. Variant phrasings: "oserror libgomp.so.1 cannot open shared object file", "lightgbm libgomp.so.1 not found", "import sklearn libgomp missing docker". Edge cases: conda users can install the runtime into the env instead (conda install libgomp from conda-forge) when they have no sudo. On multi-stage builds the runtime is needed wherever the binary runs, which is the final stage only.

Context: libgomp is GCC's OpenMP runtime. Native libraries built with OpenMP, including the wheels for LightGBM, XGBoost, scikit-learn components, and many geospatial and scientific packages, link against it but do not bundle it, because it is expected to come from the operating system. Minimal container images and slim server installs often ship without it, so the first import of such a package fails in the dynamic linker with this error even though the Python package itself installed cleanly.

Source: libgomp is GCC's OpenMP runtime. Native libraries built with OpenMP, including the wheels for LightGBM, XGBoost, scikit-learn components, and many geospatial and scientific packages, link against it but do not bundle it, because it is expected to come from the operating system. Minimal container images and slim server installs often ship without it, so the first import of such a package fails in the dynamic linker with this error even though the Python package itself installed cleanly.

Verified resolution: Short answer: install the OpenMP runtime from your OS package manager. On Debian/Ubuntu that is the libgomp1 package; pip cannot fix this one because the missing piece is a system library, not a Python package. `` error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory 1. Confirm the diagnosis: ldconfig -p | grep libgomp returns nothing, and ldd on the failing package's native library (for Python packages, the .so inside site-packages) shows libgomp.so.1 as not found. Expected: both checks agree the runtime is absent. 2. Install it for your platform. Debian/Ubuntu: sudo apt-get update && sudo apt-get install -y libgomp1. RHEL/Fedora family: sudo dnf install -y libgomp. Alpine: apk add libgomp. macOS uses a different runtime name: brew install libomp. Expected: ldconfig -p | grep libgomp` now lists libgomp.so.1. 3. Re-run the import or program. Expected: it loads with no loader error. In Python, verify with a plain import of the package that failed. 4. In Docker, add the install to the Dockerfile (apt-get install libgomp1 in the runtime stage, not just the build stage) and rebuild. Expected: a fresh container from the image imports cleanly; a fix applied by hand inside a running container disappears on restart. Root cause: OpenMP-enabled binaries declare libgomp.so.1 as a needed library, and the dynamic linker resolves needed libraries only from system paths. Distroless and slim base images omit compiler runtimes, so the dependency that the wheel author assumed would always be there is missing. When to use: Linux or container environments where a native or Python ML/scientific package fails at load time with this error. When NOT to use: if libgomp is installed but the error names a version symbol (for example GOMP_4.5 not found), the installed runtime is too old for the binary; upgrade the runtime or use a newer base image rather than reinstalling the same package. Variant phrasings: "oserror libgomp.so.1 cannot open shared object file", "lightgbm libgomp.so.1 not found", "import sklearn libgomp missing docker". Edge cases: conda users can install the runtime into the env instead (conda install libgomp from conda-forge) when they have no sudo. On multi-stage builds the runtime is needed wherever the binary runs, which is the final stage only.

Source URL: https://pypi.org/project/gpboost/1.6.6/

Not specified by the original author.

TL;DR: lightgbm needs the OpenMP runtime library and your Linux box does not have it. Install the libgomp system package and the import works.

The error

OSError: libgomp.so.1: cannot open shared object file: No such file or directory

Fix it

1. Install the OpenMP runtime. On Debian/Ubuntu:

   sudo apt install libgomp1

   On RHEL/Fedora: sudo dnf install libgomp. Expected: package installs.

2. Verify the library resolves:

   ldconfig -p | grep libgomp

   Expected: a line showing libgomp.so.1.

3. Retry:

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

   Expected: prints the version.

4. Alternative: install lightgbm from conda-forge, which bundles the runtime:

   conda install -c conda-forge lightgbm

When this applies

Use this when import lightgbm on Linux raises the libgomp.so.1 error.

When it does not apply

On macOS the equivalent missing library is libomp.dylib (brew install libomp). If a different .so is missing, install that library instead.

Compatibility

Linux, lightgbm pip wheels that link the system OpenMP.

Root cause

lightgbm's compiled core links against libgomp for OpenMP parallelism. Minimal docker images and stripped servers often lack the libgomp runtime package, so the dynamic loader fails at import.

Edge cases

In docker, add the package to the Dockerfile so rebuilds do not regress. On clusters without sudo, the conda-forge build is the way out since it carries its own runtime.

The Ampel-HU-astro README (AmpelAstro/Ampel-HU-astro) documents this exact failure: importing lightgbm fails with OSError: libgomp.so.1: cannot open shared object file on systems without the OpenMP runtime. The documented fix is installing the libgomp system package (e.g. the libgomp1 OS package) so the shared library resolves, after which import lightgbm succeeds. Source: https://github.com/AmpelAstro/Ampel-HU-astro

Not specified by the original author.

Short answer: find where libcudart.so.13 actually lives on the machine, then put that directory on the linker search path, or install the matching CUDA 13 runtime. Do not symlink a different major version in its place. `` error while loading shared libraries: libcudart.so.13: cannot open shared object file: No such file or directory 1. Locate the library: find / -name "libcudart.so*" 2>/dev/null. Two useful outcomes: a path under a CUDA install (for example the cuda lib64 directory) or a path inside your Python env (site-packages/nvidia/cu13/lib). If the search returns nothing, the runtime is genuinely absent; go to step 3. 2. If it exists, expose it to the linker for the current shell: export LD_LIBRARY_PATH with that directory prepended, then rerun the program. Expected: the program starts, or ldd YOURBINARY | grep cudart now resolves to a real path instead of not found. For system CUDA installs, adding the cuda lib64 directory to a file under /etc/ld.so.conf.d and running sudo ldconfig makes it permanent. 3. If it does not exist, install the CUDA 13 runtime: the cuda-toolkit-13 packages from NVIDIA's repo, or inside a Python-only stack python -m pip install nvidia-cuda-runtime-cu13 (then still apply step 2 to its lib directory). Expected: the find from step 1 now returns a libcudart.so.13 path. 4. Verify versions line up: nvidia-smi` shows the driver's maximum CUDA version (13.0 or higher is needed for a CUDA 13 runtime) and the failing program's expected runtime. A driver too old for CUDA 13 cannot be fixed by paths; update the driver or rebuild/reinstall the program against CUDA 12. Root cause: the linker only searches its configured paths (ld config, LDLIBRARY_PATH, standard lib dirs). CUDA runtimes installed by pip wheels live outside all of them, and a runtime of the wrong major version is invisible in a different way: present, but never a match for the .so.13 name the binary requests. When to use: Linux binaries or Python GPU packages (vLLM, PyTorch extensions, TensorRT tools) failing at startup with this exact loader error. When NOT to use: if ldd resolves cudart but the program then fails on a GLIBC version message, that is a libc mismatch, not a search-path problem. In Docker, fix the image (use a cuda runtime base image or install the runtime in the Dockerfile) instead of exporting paths at container start. Variant phrasings: "importerror libcudart.so.13 cannot open shared object file", "vllm libcudart.so.13 not found", "libcudart.so.13 missing ubuntu". Edge cases: conda environments put the runtime under the env's lib directory; the same export works with that path. Never copy or symlink a libcudart from another CUDA major version: the loader will accept the name and the program will fail later with undefined symbols.

Context: A binary linked against the CUDA 13 runtime starts, the dynamic linker looks for libcudart.so.13, and it is either not installed or not in any directory the linker searches. The .so.13 suffix is a major-version contract: a CUDA 12 runtime does not satisfy it. The current twist is that pip-installed GPU stacks (vLLM, PyTorch CUDA wheels) often ship this library inside the Python environment under site-packages/nvidia, a directory the system linker never searches by default, so the file exists on disk while the error insists it cannot be found.

Source: A binary linked against the CUDA 13 runtime starts, the dynamic linker looks for libcudart.so.13, and it is either not installed or not in any directory the linker searches. The .so.13 suffix is a major-version contract: a CUDA 12 runtime does not satisfy it. The current twist is that pip-installed GPU stacks (vLLM, PyTorch CUDA wheels) often ship this library inside the Python environment under site-packages/nvidia, a directory the system linker never searches by default, so the file exists on disk while the error insists it cannot be found.

Verified resolution: Short answer: find where libcudart.so.13 actually lives on the machine, then put that directory on the linker search path, or install the matching CUDA 13 runtime. Do not symlink a different major version in its place. `` error while loading shared libraries: libcudart.so.13: cannot open shared object file: No such file or directory 1. Locate the library: find / -name "libcudart.so*" 2>/dev/null. Two useful outcomes: a path under a CUDA install (for example the cuda lib64 directory) or a path inside your Python env (site-packages/nvidia/cu13/lib). If the search returns nothing, the runtime is genuinely absent; go to step 3. 2. If it exists, expose it to the linker for the current shell: export LD_LIBRARY_PATH with that directory prepended, then rerun the program. Expected: the program starts, or ldd YOURBINARY | grep cudart now resolves to a real path instead of not found. For system CUDA installs, adding the cuda lib64 directory to a file under /etc/ld.so.conf.d and running sudo ldconfig makes it permanent. 3. If it does not exist, install the CUDA 13 runtime: the cuda-toolkit-13 packages from NVIDIA's repo, or inside a Python-only stack python -m pip install nvidia-cuda-runtime-cu13 (then still apply step 2 to its lib directory). Expected: the find from step 1 now returns a libcudart.so.13 path. 4. Verify versions line up: nvidia-smi` shows the driver's maximum CUDA version (13.0 or higher is needed for a CUDA 13 runtime) and the failing program's expected runtime. A driver too old for CUDA 13 cannot be fixed by paths; update the driver or rebuild/reinstall the program against CUDA 12. Root cause: the linker only searches its configured paths (ld config, LDLIBRARY_PATH, standard lib dirs). CUDA runtimes installed by pip wheels live outside all of them, and a runtime of the wrong major version is invisible in a different way: present, but never a match for the .so.13 name the binary requests. When to use: Linux binaries or Python GPU packages (vLLM, PyTorch extensions, TensorRT tools) failing at startup with this exact loader error. When NOT to use: if ldd resolves cudart but the program then fails on a GLIBC version message, that is a libc mismatch, not a search-path problem. In Docker, fix the image (use a cuda runtime base image or install the runtime in the Dockerfile) instead of exporting paths at container start. Variant phrasings: "importerror libcudart.so.13 cannot open shared object file", "vllm libcudart.so.13 not found", "libcudart.so.13 missing ubuntu". Edge cases: conda environments put the runtime under the env's lib directory; the same export works with that path. Never copy or symlink a libcudart from another CUDA major version: the loader will accept the name and the program will fail later with undefined symbols.

Source URL: https://codechefvaibhavkashyap.medium.com/deploying-vllm-on-a-gcp-deep-learning-vm-my-real-world-journey-with-nvidia-l4-cuda-and-gemma-31b-464c94019f5a