[vtk-developers] Fwd: OSX build links directly with Python binary - avoidable?

David Gobbi david.gobbi at gmail.com
Mon May 4 08:58:03 EDT 2015

Hi Matthew,

Frameworks/Python.framework/Versions/2.7/Python is a framework
library (a dylib without a suffix).  In my build (probably yours too),
cmake links all VTK python libs to libpython2.7.dylib, which is a
symbolic link to Frameworks/Python.framework/Versions/2.7/Python.

So this "binary" is none other than the libpython dynamic library,
and it isn't too surprising to have it show up with "otool -L".

I tried manually linking libCommonCorePython.so without using
libpython in the link line, and it worked fine. And linking the other
libs like libvtkWrappingPython27Core without libpython works if
I add "-undefined dynamic_lookup".  So this seems like a
reasonable thing to do.

 - David

On Sat, May 2, 2015 at 3:40 PM, Matthew Brett <matthew.brett at gmail.com>

> Hi,
> I have spent a little time trying to build OSX wheels [1] for VTK.
> These would be very useful for an automated binary install of VTK for
> OSX Python.
> Short version : vtk python libraries link directly against the Python
> binary, making more general packaging impossible.
> Long version:
> My plan was to first do an install into the Python site-packages, copy
> and do a relative path relink of the library dependencies into a
> `.dylibs` directory [2] and then package the files into a wheel.
> My first shot was using the homebrew installation:
> brew install vtk --with-python --with-qt --with-matplotlib
> This installation can't be used with a Python other than the one it is
> compiled with, because it links directly to the Python binary.  The
> output from this:
> cd /usr/local/Cellar/vtk/6.2.0/lib/python2.7/site-packages/vtk
> otool -L vtkCommonCorePython.so
> includes:
> /usr/local/opt/python/Frameworks/Python.framework/Versions/2.7/Python
> (compatibility version 2.7.0, current version 2.7.0)
> This is true for many (?all) other vtk compiled extension modules.
> Is there any reason that this library has to link directly the Python
> binary?  It makes it impossible to make a package that will install
> for a Python other than the one it was built with, and at the same
> path.
> I believe standard practice is to use " -undefined dynamic_lookup "
> for Python symbols loaded from extension modules, but I am happy to be
> corrected.
> Cheers,
> Matthew
> [1] https://github.com/MacPython/wiki/wiki/Spinning-wheels
> [2] https://github.com/matthew-brett/delocate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150504/9dc14bac/attachment.html>

More information about the vtk-developers mailing list