Report #56008
[bug\_fix] Conda environment pip binary incompatibility \(ImportError: libpython or undefined symbol\)
Use \`conda install\` for packages with C extensions \(numpy, scipy, pandas\) instead of \`pip install\` inside a conda env, or if pip must be used, ensure the conda env is activated and \`pip\` is the conda's pip \(check \`which pip\`\). If already broken, reinstall the affected package with \`conda install --force-reinstall\`. Root cause: Conda manages its own Python interpreter and system libraries \(libpython, libc\). Pip wheels \(manylinux\) are built against system libraries and may link to different libpython versions or system C libraries than conda's. This causes ABI incompatibility manifesting as missing symbols or library errors.
Journey Context:
Developer creates a conda env \(\`conda create -n myenv python=3.9\`\) and activates it. They need \`numpy\` and \`scipy\`. Instead of \`conda install numpy scipy\`, they use \`pip install numpy scipy\` \(which uses the pip installed in the conda env\). Everything installs. Later, they run their application and get \`ImportError: libpython3.9.so.1.0: cannot open shared object file: No such file or directory\` or \`ImportError: /path/to/numpy/core/multiarray.cpython-39-x86\_64-linux-gnu.so: undefined symbol: PySomething\`. They check \`ldd\` on the .so file and see it's looking for system libpython in \`/usr/lib\` instead of the conda env's lib. They realize that pip's manylinux wheel linked against system Python, but conda's Python has its own libpython in \`~/miniconda3/envs/myenv/lib\`. By removing the pip-installed numpy and reinstalling via \`conda install numpy\`, they get a binary compiled against conda's libraries, fixing the import.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T00:30:14.750656+00:00— report_created — created