Hi,
On Sat, Jul 2, 2016 at 6:58 AM, Ronald Oussoren <ronaldousso...@mac.com> wrote:
> I don't think this is possible with macholib, py2app is the primary use case
> for developing macholib and doesn't need this functionality.
>
> Why do you want to do this? I'd expect there to be a real dependency on the
> library (by using a symbol from it) and removing the load command would just
> cause a crash. It might be possible to change the load command to a weak
> linking one, although I don't know if that would require changes to the
> loaded symbols as well. Anyway, afaik macholib doesn't support that either
> (yet).
Thanks for the reply.
The specific case I'm working on is trying to fix some mis-features of
the way that VTK is built on OSX. VTK gets built with cmake, and
cmake does not seem to have a good general way of dealing with the
standard method of Python linking, that is, leaving the Python symbols
undefined, to be looked up at run time [1, 2].
For example the VTK binary installer for OSX [3] has its own copy of
Python, and links directly to system Python for its symbols, making it
useless for working with other Pythons or in virtualenvs.
There's some work underway in VTK [2, 4] and cmake [5] to fix cmake to
label the Python symbols as undefined, and to look these symbols up at
run-time, but this is not yet merged with VTK or implemented in cmake.
So, I was trying some surgery on the distributed VTK installer to make
it suitable for a binary wheel, by setting the library links to be
relative to the vtk installation directory, and removing the direct
linking to the system Python binary [6].
The problem is the one you pointed out, which is that the symbol table
of the various libs specifically tell the linker to go get the Python
symbols from the linked Python binary. For example, before deleting
the Python system library from the list of libraries to be loaded:
$ nm -m vtk/lib/libvtkWrappingPython27Core-7.0.1.dylib | grep _PyBase
(undefined) external _PyBaseObject_Type (from Python)
This should be:
(undefined) external _PyBaseObject_Type (dynamically looked up)
So, yes, you're right - just deleting the library from the list isn't
enough, it requires rewriting the symbol table. It's tough because,
if I could do that, it would be possible to generate a functioning and
very useful VTK binary wheel from the current VTK install package.
Cheers,
Matthew
[1] http://blog.tim-smith.us/2015/09/python-extension-modules-os-x/
[2] https://github.com/Homebrew/homebrew-science/issues/3401
[3] http://www.vtk.org/files/release/7.0/vtkpython-7.0.0-Darwin-64bit.dmg
[4] https://gitlab.kitware.com/vtk/vtk/merge_requests/1511
[5]
https://docs.google.com/document/d/1e46rbbedffiQLHSRWwjuO9tbscOM9fXhWarL8eNhG5o/edit#
[6] https://gist.github.com/matthew-brett/2907cdb31a042c7a737902b719f4deb8
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
