import order problem

[Thomas Hisch]

dolfin always needs to be imported before mshr, otherwise an ImportError is raised:

» python -c 'import dolfin; import mshr'                                                                                                                                         
» python -c 'import mshr'               
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/thomas/miniconda/envs/py27_fenics15dev_petsc35/lib/python2.7/site-packages/mshr.py", line 32, in <module>
    _mshr = swig_import_helper()
  File "/home/thomas/miniconda/envs/py27_fenics15dev_petsc35/lib/python2.7/site-packages/mshr.py", line 28, in swig_import_helper
    _mod = imp.load_module('_mshr', fp, pathname, description)
ImportError: libslepc.so.3.5: cannot open shared object file: No such file or directory

It would help if you catch this exception in mshr and raise a new more informative exception.

[Benjamin Dam Kehlet]

The import order shouldn't matter, so something is going wrong here. I'm having trouble reproducing it. Where is libslepc.so located? Could you check with "ldd _mshr.so" and see if the paths to the external libraries looks reasonable and, in particular, if the entry with slepc refers to the actual location of libsleps.so?

[Thomas Hisch]

ldd can't find the location of certain libraries of the installed mshr library:

ldd /home/thomas/miniconda/envs/py27_fenics15dev_petsc35/lib/python2.7/site-packages/_mshr.so G 'not found'
    libmshr.so.1.4 => not found
    libdolfin.so.1.4 => not found
    libslepc.so.3.5 => not found
    libpetsc.so.3.5 => not found
    libparmetis.so => not found
    libmetis.so => not found

However, the mshr.so file in the build directory seems to be fine:

ldd /home/thomas/gitrepos/fenics/dev/mshr/build_fed_openmpi_py27/swig/_mshr.so G 'not found'

[Johannes Ring]

Have you added the location of these libraries (libmshr.so.1.4, libdolfin.so.1.4, etc.) to LD_LIBRARY_PATH?

[Thomas Hisch]

Probably this line in the output of make install is causing the not found libs in the installed _mshr.so lib.

-- Removed runtime path from "/home/thomas/miniconda/envs/py27_fenics15dev_petsc35/lib/python2.7/site-packages/_mshr.so"

copying the file from swig/_mshr.so to the location of the installed _mshr.sh fixes this issue.

[Thomas Hisch]

This issue slipped in between 817fd67 and HEAD

[Thomas Hisch]

I nailed it down to this commit: 10439cd. This causes the output of

-- Removed runtime path from "/home/thomas/miniconda/envs/py27_fenics15dev_petsc35/lib/python2.7/site-packages/_mshr.so" in make install and therefore the not-found entries in ldd

[Thomas Hisch]

How about using set_target_properties (see http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path)

[Thomas Hisch]

adding the following line to swig/CMakeLists.txt fixes this issue:

set_target_properties(${SWIG_MODULE_mshr_REAL_NAME} PROPERTIES INSTALL_RPATH_USE_LINK_PATH TRUE)

[Benjamin Dam Kehlet]

Don't let cmake remove runtime linkink paths. Resolves issue #17.

→ <<cset 4e8ee4fdc4b1>>

[Benjamin Dam Kehlet]

Thanks a lot! Hope it works now. I had no idea that cmake removes these link paths by default.