Menu ▾ ▴

#916 Create way to use non-framework python lib on OSX

2.3.x
open
nobody
None
1
2014-08-13
2014-03-27
Michael Schmuker
No

I tried to compile openbabel from github (5f0837...) on OSX 10.9 Mavericks with python extensions, using anaconda python. By default, cmake picks Apple's libpython2.7.dylib to compile the python extension against. This can be overridden by editing the CMakeCache.txt file and setting the variables PYTHON_INCLUDE_DIR and PYTHON_LIBRARY to point to the respective anaconda python files, e.g.

PYTHON_EXECUTABLE:FILEPATH=/Users/ms/anaconda/bin/python <-- cmake finds this by itself if in PATH
PYTHON_INCLUDE_DIR:PATH=/Users/ms/anaconda/include/python2.7/ <-- must be set by hand
PYTHON_LIBRARY:FILEPATH=/Users/ms/anaconda/lib/libpython2.7.dylib <-- this too.

However, after building, the openbabel module then fails to import in anaconda python, causing it to to crash:

$> ipython
Python 2.7.6 |Anaconda 1.9.1 (x86_64)| (default, Jan 10 2014, 11:23:15) 
[...]

In [1]: import openbabel
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6

It seems something is wrong with the way the _openbabel.so file in the python extensions is linked:

$> otool -L _openbabel.so 
_openbabel.so:
    libpython2.7.dylib (compatibility version 2.7.0, current version 2.7.0) 
    /Users/ms/openbabel/installation/lib/libopenbabel.4.dylib (compatibility version 4.0.0, current version 4.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)

Note that libpython2.7.dylib does not explicitely point to the anaconda python lib, but instead is specified as a simple file name. I suppose this causes the dynamic linker to use the system python lib at runtime. The system lib is from python 2.7.5, while anaconda comes with 2.7.6. The version mismatch is most likely responsible for the crash.

This mismatch can be fixed using install_name_tool to explicitely set the full path to the python lib:

install_name_tool -change libpython2.7.dylib /Users/ms/anaconda/lib/libpython2.7.dylib _openbabel.so

With this treatment, the import in anaconda python succeeds without error.

I don't know enough about linker directives to really figure out what's going wrong during the build. Is it possible to supply the linker with the full path to the specified python lib?

Discussion