You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not really sure if this is a namaster issue or an issue meant for conda, but I figured I'd document it here in case others ran into it or there was a better solution.
I was trying to build a new conda environment including namaster, but was having issues like the following:
zatkins@della8:~$ python -c "import pymaster"
Traceback (most recent call last):
File "", line 1, in
File "/home/zatkins/.conda/envs/pspy-della8/lib/python3.10/site-packages/pymaster/init.py", line 50, in
from pymaster import nmtlib as lib # noqa
File "/home/zatkins/.conda/envs/pspy-della8/lib/python3.10/site-packages/pymaster/nmtlib.py", line 13, in
import _nmtlib
ImportError: libgsl.so.25: cannot open shared object file: No such file or directory
Indeed, going into my new environment's site-packages folder revealed that library was not linked when generating the _nmtlib .so file:
zatkins@della8:~$ ldd _nmtlib.cpython-310-x86_64-linux-gnu.so
libgsl.so.25 => not found
This was apparently because the gsl version grabbed by conda as a dependency of namaster was gsl 2.7.1, which only contains a copy of libgsl.so.27 (see related issues here and here). Indeed, my conda lib did contain libgsl.so.27 where I guess (conda? namaster?) was expecting libgsl.so.25 to be, and so the linking did not occur.
I wanted a pure conda solution (e.g., not symlinking my libgsl.so.27 to libgsl.so.25). The issue is that the semantic versioning of gsl on the defaults anaconda channel goes 2.7, then 2.7.1, so I think specifying gsl=2.7 in my conda install command still grabs 2.7.1 (vs. if gsl had a 2.7.0 version). Finally, the solution was to enforce gsl is grabbed from the conda-forge channel, which luckily only has gsl 2.7 as the latest version.
The mysteries of when packages are linked to libraries, and by whom, for a conda distribution elude me, but hopefully this helps someone in the future.
The text was updated successfully, but these errors were encountered:
I'm not really sure if this is a namaster issue or an issue meant for conda, but I figured I'd document it here in case others ran into it or there was a better solution.
I was trying to build a new conda environment including namaster, but was having issues like the following:
Indeed, going into my new environment's site-packages folder revealed that library was not linked when generating the _nmtlib .so file:
This was apparently because the gsl version grabbed by conda as a dependency of namaster was gsl 2.7.1, which only contains a copy of libgsl.so.27 (see related issues here and here). Indeed, my conda lib did contain libgsl.so.27 where I guess (conda? namaster?) was expecting libgsl.so.25 to be, and so the linking did not occur.
I wanted a pure conda solution (e.g., not symlinking my libgsl.so.27 to libgsl.so.25). The issue is that the semantic versioning of gsl on the defaults anaconda channel goes 2.7, then 2.7.1, so I think specifying gsl=2.7 in my conda install command still grabs 2.7.1 (vs. if gsl had a 2.7.0 version). Finally, the solution was to enforce gsl is grabbed from the conda-forge channel, which luckily only has gsl 2.7 as the latest version.
The mysteries of when packages are linked to libraries, and by whom, for a conda distribution elude me, but hopefully this helps someone in the future.
The text was updated successfully, but these errors were encountered: