In bzip2-1.0.6 it appears only libbz2.a is distributed. This creates difficulty to port prebuilt binaries that uses libbz2. If the build platform provides a libbz2.so it is usually preferred and the binaries are linked with libbz2.so instead of libbz2.a provided by conda. As a result, when the binaries are deployed by conda to a platform without libbz2.so, the code crashes with an error:
~/.conda/envs/bccp/lib/python3.5/site-packages/fitsio/fitslib.py in <module>()
27 import warnings
---> 29 from . import _fitsio_wrap
30 from .util import FITSRuntimeWarning, cfitsio_version
ImportError: libbz2.so.1.0: cannot open shared object file: No such file or directory
Related to bccp/conda-channel-bccp#8
I'm trying to use 'pysam' via conda install and am getting the same error:
>>> import pysam Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/n/projects/anaconda2/lib/python2.7/site-packages/pysam/__init__.py", line 5, in <module> from pysam.libchtslib import * ImportError: libbz2.so.1.0: cannot open shared object file: No such file or directory
I've attempted to install bz2 via conda as well, but like stated above the only instance of the package I can find is 'libbz2.a'.
Just got caught by the same issue. In my situation, the reason was that:
"defaults" channel: provides bzip2-1.0.6 without .so
"conda-forge" channel: provides bzip2-1.0.6 with .so
To resolve, either set conda-forge as a higher-priority channel or type:
conda install --override-channels -c conda-forge bzip2
iromeo, mvelinder, mjjlou, zyxue, DavidArenburg, konsolerr, TomSmithCGAT, amalthomas111, stuber, FushanLi, and 6 more reacted with thumbs up emoji
jonstrutz11, tangboyun, and monti-python reacted with hooray emoji
All reactions
Hi, I prefer to work with the default channels because it is not clear if there is any policy conda-forge overwrites a default channel package. I suppose anaconda have a policy of not distributing the .so file because it prefers static linking (for a variety of good reasons) -- most other Linux distributors do prefer dynamic linking, which may have motivated conda-forge's packaging policy.
Here is what I did to fix our package's yaml recipe. It's a one line change.
bccp/conda-channel-bccp@ae73b3f#diff-2a1bf10256fa18f4a657af078af914c8L18
