<div dir="ltr">Hi Matthew,<div><br></div><div>Frameworks/Python.framework/Versions/2.7/Python is a framework</div><div>library (a dylib without a suffix).  In my build (probably yours too),</div><div>cmake links all VTK python libs to libpython2.7.dylib, which is a</div><div>symbolic link to Frameworks/Python.framework/Versions/2.7/Python.</div>







<div><br></div><div>So this "binary" is none other than the libpython dynamic library,</div><div>and it isn't too surprising to have it show up with "otool -L".</div><div><br></div><div>I tried manually linking libCommonCorePython.so without using</div><div>libpython in the link line, and it worked fine. And linking the other</div><div>libs like libvtkWrappingPython27Core without libpython works if</div><div>I add "-undefined dynamic_lookup".  So this seems like a</div><div>reasonable thing to do.</div><div><br></div><div> - David</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 2, 2015 at 3:40 PM, Matthew Brett <span dir="ltr"><<a href="mailto:matthew.brett@gmail.com" target="_blank">matthew.brett@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
I have spent a little time trying to build OSX wheels [1] for VTK.<br>
These would be very useful for an automated binary install of VTK for<br>
OSX Python.<br>
<br>
Short version : vtk python libraries link directly against the Python<br>
binary, making more general packaging impossible.<br>
<br>
Long version:<br>
<br>
My plan was to first do an install into the Python site-packages, copy<br>
and do a relative path relink of the library dependencies into a<br>
`.dylibs` directory [2] and then package the files into a wheel.<br>
<br>
My first shot was using the homebrew installation:<br>
<br>
brew install vtk --with-python --with-qt --with-matplotlib<br>
<br>
This installation can't be used with a Python other than the one it is<br>
compiled with, because it links directly to the Python binary.  The<br>
output from this:<br>
<br>
cd /usr/local/Cellar/vtk/6.2.0/lib/python2.7/site-packages/vtk<br>
otool -L vtkCommonCorePython.so<br>
<br>
includes:<br>
<br>
/usr/local/opt/python/Frameworks/Python.framework/Versions/2.7/Python<br>
(compatibility version 2.7.0, current version 2.7.0)<br>
<br>
This is true for many (?all) other vtk compiled extension modules.<br>
<br>
Is there any reason that this library has to link directly the Python<br>
binary?  It makes it impossible to make a package that will install<br>
for a Python other than the one it was built with, and at the same<br>
path.<br>
<br>
I believe standard practice is to use " -undefined dynamic_lookup "<br>
for Python symbols loaded from extension modules, but I am happy to be<br>
corrected.<br>
<br>
Cheers,<br>
<br>
Matthew<br>
<br>
[1] <a href="https://github.com/MacPython/wiki/wiki/Spinning-wheels" target="_blank">https://github.com/MacPython/wiki/wiki/Spinning-wheels</a><br>
[2] <a href="https://github.com/matthew-brett/delocate" target="_blank">https://github.com/matthew-brett/delocate</a><br>
</blockquote></div><br></div></div>