| 2012-08-28 06:59:07 |
su_v |
bug |
|
|
added bug |
| 2012-08-28 07:00:00 |
su_v |
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_path/../Resources/lib' no is relative to
> 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://bugs.launchpad.net/inkscape/+bug/738973/comments/21>
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(/Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so, 2): Symbol not found: _exsltDateXpathCtxtRegister
Referenced from: /Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so
Expected in: /usr/lib/libexslt.0.dylib
in /Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so
Comparing libexslt loaded by system python with the one installed in MacPorts:
Chillida:macosx su_v$ otool -L /usr/lib/libexslt.0.dylib/usr/lib/libexslt.0.dylib:
/usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.13.0)
/usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.24.0)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 46.1.0)
Chillida:macosx su_v$ otool -L /Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib:
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.15.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.6)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
Chillida:macosx su_v$
$ port provides /Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib is provided by: libxslt
AFAIK if the versions of libexslt don't match, extensions fail - we had this issue 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 it 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. |
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_path/../Resources/lib' no is relative to
> 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://bugs.launchpad.net/inkscape/+bug/738973/comments/21>
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(/Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so, 2): Symbol not found: _exsltDateXpathCtxtRegister
Referenced from: /Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so
Expected in: /usr/lib/libexslt.0.dylib
in /Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so
Comparing libexslt loaded by system python with the one installed in MacPorts:
Chillida:macosx su_v$ otool -L /usr/lib/libexslt.0.dylib
/usr/lib/libexslt.0.dylib:
/usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.13.0)
/usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.24.0)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 46.1.0)
Chillida:macosx su_v$ otool -L /Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib:
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.15.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.6)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
Chillida:macosx su_v$
$ port provides /Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib is provided by: libxslt
AFAIK if the versions of libexslt don't match, extensions fail - we had this issue 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 it 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. |
|
| 2012-08-28 07:00:35 |
su_v |
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_path/../Resources/lib' no is relative to
> 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://bugs.launchpad.net/inkscape/+bug/738973/comments/21>
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(/Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so, 2): Symbol not found: _exsltDateXpathCtxtRegister
Referenced from: /Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so
Expected in: /usr/lib/libexslt.0.dylib
in /Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so
Comparing libexslt loaded by system python with the one installed in MacPorts:
Chillida:macosx su_v$ otool -L /usr/lib/libexslt.0.dylib
/usr/lib/libexslt.0.dylib:
/usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.13.0)
/usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.24.0)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 46.1.0)
Chillida:macosx su_v$ otool -L /Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib:
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.15.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.6)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
Chillida:macosx su_v$
$ port provides /Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib is provided by: libxslt
AFAIK if the versions of libexslt don't match, extensions fail - we had this issue 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 it 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. |
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_path/../Resources/lib' no is relative to
> 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://bugs.launchpad.net/inkscape/+bug/738973/comments/21>
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(/Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so, 2): Symbol not found: _exsltDateXpathCtxtRegister
Referenced from: /Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so
Expected in: /usr/lib/libexslt.0.dylib
in /Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so
Comparing libexslt loaded by system python with the one installed in MacPorts:
Chillida:macosx su_v$ otool -L /usr/lib/libexslt.0.dylib
/usr/lib/libexslt.0.dylib:
/usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.13.0)
/usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.24.0)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 46.1.0)
Chillida:macosx su_v$ otool -L /Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib:
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.15.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.6)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
Chillida:macosx su_v$
$ port provides /Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib is provided by: libxslt
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 it 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. |
|
| 2012-08-28 07:01:14 |
su_v |
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_path/../Resources/lib' no is relative to
> 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://bugs.launchpad.net/inkscape/+bug/738973/comments/21>
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(/Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so, 2): Symbol not found: _exsltDateXpathCtxtRegister
Referenced from: /Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so
Expected in: /usr/lib/libexslt.0.dylib
in /Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so
Comparing libexslt loaded by system python with the one installed in MacPorts:
Chillida:macosx su_v$ otool -L /usr/lib/libexslt.0.dylib
/usr/lib/libexslt.0.dylib:
/usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.13.0)
/usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.24.0)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 46.1.0)
Chillida:macosx su_v$ otool -L /Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib:
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.15.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.6)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
Chillida:macosx su_v$
$ port provides /Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib is provided by: libxslt
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 it 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. |
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_path/../Resources/lib' no is relative to
> 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://bugs.launchpad.net/inkscape/+bug/738973/comments/21>
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(/Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so, 2): Symbol not found: _exsltDateXpathCtxtRegister
Referenced from: /Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so
Expected in: /usr/lib/libexslt.0.dylib
in /Volumes/cyan/src/inkscape/inkscape-dev-osx/packaging/macosx/inkscape.app/Contents/Resources/python/site-package/lxml/etree.so
Comparing libexslt loaded by system python with the one installed in MacPorts:
Chillida:macosx su_v$ otool -L /usr/lib/libexslt.0.dylib
/usr/lib/libexslt.0.dylib:
/usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.13.0)
/usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.24.0)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 46.1.0)
Chillida:macosx su_v$ otool -L /Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib:
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.15.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.6)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
Chillida:macosx su_v$
$ port provides /Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib
/Volumes/cyan/mp-quartz/with-a-long-long-long-directory-name/lib/libexslt.0.dylib is provided by: libxslt
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. |
|
| 2012-08-28 07:07:42 |
su_v |
branch linked |
|
lp:~inkscape.dev/inkscape/dev-osx |
|
| 2012-08-29 12:46:55 |
su_v |
inkscape: importance |
Undecided |
High |
|
| 2012-08-29 12:47:05 |
su_v |
inkscape: importance |
High |
Undecided |
|
| 2012-08-29 12:47:19 |
su_v |
inkscape: importance |
Undecided |
Medium |
|
| 2012-08-29 12:47:29 |
su_v |
inkscape: status |
New |
In Progress |
|
| 2012-09-04 18:48:08 |
su_v |
summary |
[inkscape-quartz] extensions fail with 'Symbol not found: _exsltDateXpathCtxtRegister' |
[inkscape-quartz] gtk-mac-bundler: include python modules (and runtime) for extensions |
|
| 2014-11-06 04:33:25 |
su_v |
inkscape: status |
In Progress |
Invalid |
|
| 2014-11-06 04:33:25 |
su_v |
inkscape: assignee |
Gellule (gellule-xg) |
|
|
| 2017-01-12 16:12:09 |
su_v |
tags |
extensions-plugins gtk-osx packaging |
extensions-plugins gtk-quartz packaging |
|
| 2017-01-12 16:13:49 |
su_v |
tags |
extensions-plugins gtk-quartz packaging |
extensions-plugins gtk-osx gtk-quartz packaging |
|
