ImportError: librascal.so: cannot open shared object file: No such file or directory

[cbenmahm]

Hello!

I installed librascal using pip as instructed in the README file:pip install ..

I had no problem importing rascal: import rascal. However, I was not able to import the SphericalInvariants representation or representations . I attach the error message for reference.

`ImportError Traceback (most recent call last)

in 1 import rascal 2 import ase.io ----> 3 from rascal import representations#SphericalInvariants as SOAP 4 from ase import Atoms 5 ~/miniconda3/envs/py37/lib/python3.7/site-packages/rascal/representations/__init__.py in ----> 1 from .coulomb_matrix import SortedCoulombMatrix 2 from .spherical_expansion import SphericalExpansion 3 from .spherical_invariants import SphericalInvariants 4 from .spherical_covariants import SphericalCovariants ~/miniconda3/envs/py37/lib/python3.7/site-packages/rascal/representations/coulomb_matrix.py in 2 import json 3 ----> 4 from ..neighbourlist import AtomsList 5 from .base import CalculatorFactory 6 from ..utils import FactoryPool ~/miniconda3/envs/py37/lib/python3.7/site-packages/rascal/neighbourlist/__init__.py in ----> 1 from .structure_manager import AtomsList, get_neighbourlist, convert_to_structure_list ~/miniconda3/envs/py37/lib/python3.7/site-packages/rascal/neighbourlist/structure_manager.py in 5 import numpy as np 6 ----> 7 from ..lib import neighbour_list 8 from .base import (NeighbourListFactory, is_valid_structure, 9 adapt_structure, StructureCollectionFactory) ~/miniconda3/envs/py37/lib/python3.7/site-packages/rascal/lib/__init__.py in ----> 1 from ._rascal import (neighbour_list, models, 2 representation_calculators, utils) 3 4 from ._rascal.models import kernels 5 from ._rascal.utils import sparsification ImportError: librascal.so: cannot open shared object file: No such file or directory`

[cbenmahm]

This has been solved in PR #265

[max-veit]

It has? How? I've been getting the same error (and have to set LD_LIBRARY_PATH explicitly each time as a workaround)

[felixmusil]

it is in fixed in #265

[max-veit]

Ok, but what was the actual problem? Where was this introduced (so we know not to do it again)?

[felixmusil]

the several RPATH were overwritten over one another instead of being appended.

[Luthaf]

It should have been fixed as a separated PR though. Giant PR with multiple unrelated changes are not ideal for review and knowing why/when a given change was made

[max-veit]

I agree in principle, but what do we do about it? Avoid changing cmake parameters in unrelated pull requests?

[Luthaf]

Send different PR for unrelated changes would be my preferred solution 😃. I often change branches while working on a feature to send a separate refactoring/cleanup/fix PR.

[max-veit]

Yep, though it can be a pain if you have features that depend on one another (or if you want to test a combination of features in development). I know it can be done with some git-fu, but learning that requires a dedication of time and effort many developers on this project are unwilling or unable to invest.

[Luthaf]

Well, I would disagree that learning said git-fu is harder than learning how to use VASP or LAMMPS. Anyway, my point is more "please try to send small PR containing only one change", but I should survive even if this is not followed 😄