Mac OS X, problem with shared object "dylib" in import_helper, ImportError: No module named libmodena
sigveka opened this issue · 2 comments
I was having problems importing the Python module "modena" as the error message shows:
user@machine$ cd MoDeNa/examples/twoTanks
user@machine$ ./initModels
Traceback (most recent call last):
File "./initModels", line 42, in <module>
from modena import ForwardMappingModel, BackwardMappingModel, SurrogateModel, CFunction
File "/Users/<XXXX>/lib/python2.7/site-packages/modena/__init__.py", line 56, in <module>
libmodena = import_helper()
File "/Users/<XXXX>/lib/python2.7/site-packages/modena/__init__.py", line 48, in import_helper
import libmodena
ImportError: No module named libmodena
The root of the problem turned out to be that Python has a problem with shared objects with dylib
extension, for some reason Python can not find libmodena.dylib
in $HOME/lib
.
The error was "fixed" by adding the symbolic libmodena.so
link pointing to libmodena.dylib
.
Open a Terminal window and change to the directory containing the dynamic libraries:
user@machine$ cd ${HOME}/lib
(not necessary just for information) The problem is that Python does not seem to find the shared objects (which on a Mac has the extension dylib
). While it is possible to change the extension to .so
, this did not solve the problem for me.
user@machine$ ls -la
-rwxr-xr-x 1 root staff 8.2K May 14 23:21 libfmodena.dylib*
-rwxr-xr-x 1 root staff 25K May 14 23:21 libmodena.0.5.dylib*
lrwxr-xr-x 1 root staff 19B May 14 23:11 libmodena.1.dylib@ -> libmodena.0.5.dylib
lrwxr-xr-x 1 root staff 17B May 14 23:11 libmodena.dylib@ -> libmodena.1.dylib
The solution was to create a symbolic link as follows:
user@machine$ ln -s libmodena.dylib libmodena.so
user@machine$ ls -la *.so
lrwxr-xr-x 1 sigveka staff 15B May 14 23:37 libmodena.so@ -> libmodena.dylib
As shown below this solved the problem, however it remains unclear why Python does not support dylib
extensions.
user@machine$ python
>>> import modena
>>> dir(modena)
['BackwardMappingModel', 'CFunction', 'ExtendSpaceStochasticSampling', 'FWAction', 'FWSerializable',
'FireTaskMeta', 'Firework', 'FloatVector', 'ForwardMappingModel', 'ImproveErrorStrategy', 'InitialPoints',
'InitialisationStrategy', 'MODENA_INSTALL_DIR', 'NonLinFitWithErrorContol', 'OutOfBoundsStrategy',
'ParameterFittingStrategy', 'SamplingStrategy', 'StochasticSampling', 'Strategy', 'SurrogateModel',
'Terminal', 'Workflow', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__',
'__version__', 'abc', 'array', 'choice', 'defaultdict', 'explicit_serialize', 'get_distribution', 'importr', 'lhs',
'libmodena', 'modena', 'nlmrt', 'os', 'recursive_deserialize', 'recursive_serialize', 'rinterface', 'robjects',
'seed', 'serialize_fw', 'six', 'term']
Hi Sigve,
please try putting something like
if(APPLE)
set(CMAKE_SHARED_LIBRARY_SUFFIX ".so")
endif(APPLE)
into
src/src/CMakeLists.txt
and check whether the examples still work.
Henrik
Fantastic, that seems to be a permanent solution to the problem.
A comment from stackoverflow regarding importing dylib Python modules on OS-X:
"Just use *.so as your module extensions in OS X too. I have a vague memory of not being able to load .dylib's and it turning out to be an issue with python itself. . . but I can't find the mailing list post now.
However, rest assured you're following standard practice by using *.so's even on OS X. The only *.dylib's in the entire framework are the libsvn_swig ones.-"