error while loading shared libraries: libgomp.so.1: cannot open shared object file: no such file or directory

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/