[inkscape-quartz] gtk-mac-bundler: include python modules (and runtime) for extensions
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
Invalid
|
Medium
|
Unassigned |
Bug Description
Follow-up to
Bug #738973 “Issues with inkscape-quartz blueprint”
From comment 21:
> 1) The proposed solution for python extensions can't work (same issue
> was encountered with old launcher…)
>
> The install_names of the two *.so libs from lxml are changed to be
> relative to the executable of the app bundle. The extensions however
> launch a separate binary (/usr/bin/python) which can't find the required
> libraries since '@executable_
> the path of the python binary.
>
> AFAIU either you need to include a copy of a python installation (or
> a virtualenv (?)) into the app bundle, or build and link the required
> lxml module statically using the system python version (and not the
> one from MacPorts), and not run install_name_tool on its *.so libs.
>
> ('osx-lxml.sh' script in my branch compiles the python module for the
> system python (without any references to MacPorts), installs lxml
> directly into the app bundle skeleton and then only needs to be
> copied along with the rest into the final app bundle).
<https:/
Application bundle built based on r11625 of lp:~inkscape.dev/inkscape/dev-osx,
built on OS X 10.7.4 (Xcode 4.3.2)
Python-based extensions fail, apparently due to version incompatibility of shared libraries:
Error message from debug extension (which basically imports lxml, etree from lxml and numpy, and outputs the version and paths of the used python binary and loaded module):
Traceback (most recent call last):
File "debug.py", line 5, in <module>
from lxml import etree
ImportError: dlopen(
Referenced from: /Volumes/
Expected in: /usr/lib/
in /Volumes/
Comparing libexslt loaded by system python with the one installed in MacPorts:
Chillida:macosx su_v$ otool -L /usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
Chillida:macosx su_v$ otool -L /Volumes/
/Volumes/
/Volumes/
/Volumes/
/Volumes/
/Volumes/
/usr/lib/
/Volumes/
Chillida:macosx su_v$
$ port provides /Volumes/
/Volumes/
AFAIK if the versions of libexslt don't match, extensions fail - we had similar issues with the old packaging script too (when it still used DYLD_LIBRARY_PATH instead of rewriting the install names).
AFAIU it's not save to build the module(s) in MacPorts, add the files from MacPorts into the app bundle, and at runtime load the bundled module(s) with the system python version. It might work on Mountain Lion for now, but fail again if MacPorts updates libxslt to a newer version not compatible with the installed system version.
Related branches
description: | updated |
description: | updated |
description: | updated |
Changed in inkscape: | |
importance: | Undecided → High |
importance: | High → Undecided |
importance: | Undecided → Medium |
status: | New → In Progress |
summary: |
- [inkscape-quartz] extensions fail with 'Symbol not found: - _exsltDateXpathCtxtRegister' + [inkscape-quartz] gtk-mac-bundler: include python modules (and runtime) + for extensions |
tags: |
added: gtk-quartz removed: gtk-osx |
tags: | added: gtk-osx |
Maybe we should just package python2.7, numpy, and lxml altogether, and not rely on the version provided by OS X.
Was there any problem with lxml being compiled for a range of python version and architecture, and the actual version to use determined at run time?