Binary Inkscape dist crashes when MacPorts is installed

Bug #400165 reported by Jochen on 2009-07-16
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Michael Wybrow

Bug Description

The binary distribution of 0.46-2 and 0.47-pre1 crash on Leopard 10.5.7 when MacPorts is installed in parallel. When MacPorts is removed, it works just fine.

lsof reports Inkscape is opening the following files from MacPorts:

inkscape- 50711 jochen txt REG 14,2 73828 8074425 /opt/local/share/locale/de/LC_MESSAGES/
inkscape- 50711 jochen txt REG 14,2 157896 8074421 /opt/local/share/locale/de/LC_MESSAGES/
inkscape- 50711 jochen txt REG 14,2 42480 7712727 /opt/local/share/locale/de/LC_MESSAGES/
inkscape- 50711 jochen txt REG 14,2 363952 7649379 /opt/local/var/cache/fontconfig/84c0f976e30e948e99073af70f4ae876-x86.cache-2
inkscape- 50711 jochen txt REG 14,2 266128 7649335 /opt/local/var/cache/fontconfig/0f0db7876307790c19e1f91eb9095080-x86.cache-2
inkscape- 50711 jochen txt REG 14,2 265432 7649339 /opt/local/var/cache/fontconfig/1487dd4aecf3164c4a11193169052443-x86.cache-2
inkscape- 50711 jochen txt REG 14,2 19560 7649343 /opt/local/var/cache/fontconfig/a1a78d9c18cd095d3829c724810e6ffb-x86.cache-2
inkscape- 50711 jochen txt REG 14,2 18576 7649351 /opt/local/var/cache/fontconfig/bc06c1eea3e636f72101cafc3fb39508-x86.cache-2
inkscape- 50711 jochen txt REG 14,2 18760 7649355 /opt/local/var/cache/fontconfig/ba022efc551c75e21c690774bbcf5304-x86.cache-2
inkscape- 50711 jochen txt REG 14,2 64400 7649371 /opt/local/var/cache/fontconfig/79652363633577d7d713baab7f54ad8c-x86.cache-2
inkscape- 50711 jochen txt REG 14,2 25664 7748970 /opt/local/var/cache/fontconfig/0e8e53f675de3a90695eebbcc3474f93-x86.cache-2
inkscape- 50711 jochen txt REG 14,2 365552 7649383 /opt/local/var/cache/fontconfig/8d7231e6733a9725c81b40e9f55f11b1-x86.cache-2
inkscape- 50711 jochen txt REG 14,2 8507 8041241 /opt/local/share/locale/de/LC_MESSAGES/

su_v (suv-lp) on 2009-07-16
tags: added: build osx
George (gnwiii) wrote :

I tried removing /opt/local/bin from the PATH setting in:


but get:

009-07-17 11:54:29.097 defaults[83215:10b]
The domain/default pair of (kCFPreferencesAnyApplication, AppleAquaColorVariant) does not exist
2009-07-17 11:54:29.110 defaults[83216:10b]
The domain/default pair of (kCFPreferencesAnyApplication, AppleHighlightColor) does not exist

(process:83193): Gtk-WARNING **: Locale not supported by C library.
 Using the fallback 'C' locale.
Xlib: extension "RANDR" missing on display "/tmp/launch-sXhrO1/:0".

Emergency save activated!
Emergency save completed. Inkscape will close now.
If you can reproduce this crash, please file a bug at
with a detailed description of the steps leading to the crash, so we can fix it.

1) otool -L /Applications/
indicates that inkscape-bin looks for libraries in /opt/local/lib rather
than /Applications/

2) a problem in the section that attempts to add
.UTF-8 to LANG using /usr/share/locale/locale.alias

LANG="en_CA.UTF8" becomes ".UTF8"

su_v (suv-lp) wrote :

ad 1) otool -L /Applications/
see explanation in bug #392693:
 'Inkscape's libraries all have install-names of /opt/local/lib, and Inkscape uses DYLD_LIBRARY_PATH to find them…'

su_v (suv-lp) wrote :


1) launchd seems to launch an X11 version installed via macports? AFAIK Inkscape has no influence on that on Leopard 10.5.7.

2) Inkscape releases are built as universal binaries. Are you sure all (pre-installed) ports and dependencies are also installed with the same variants (including '+universal')? The wiki page <> recommends 'If you already have non-universal versions of these ports installed you may need to deactivate the port and rebuild it'.

If you need to keep ports with different variants, the best way is to set up separate instances/trees of MacPorts with a different base path (at least that's what I found recommended when searching the macports-users mailing list - archives at <>, as well as on the wiki page 'CompilingMacOsX' <>.

3) I don't know yet if DYLD_LIBRARY_PATH overrides install-names (if the libraries exist with their install-names on the local system) or acts as a fallback if the libraries can't be found under their install-names. One way to avoid possible conflicts when using both the packaged universal binaries from and local macports installations, is - as above - changing the local macports install-prefix to keep a separate tree for your own ports with a not-default install-path.

one caveat to my comments: I'm not a macports user myself yet - but preparing to do so and thus interested in any resulting conflicts and solutions.

Michael Wybrow (mjwybrow) wrote :

This problem actually started happening for me in the last couple of days after upgrading Macports.

It is fixed in svn in r21860. I will build an upload a new 0.47 package in the morning.

The problem is Inkscape trying to read incompatible fontcaches from Macports. The fix is to modify to remove the following line:

(Also, FWIW DYLD_LIBRARY_PATH does override the install-names. This wasn't an issue. But, I recently had a go at rewriting the install-names to thus not require DYLD_LIBRARY_PATH anymore. But the problem is that the path we require it too long for the space allocated to the install names in some libraries, so we might need to try doing something sneaky like installing macports in a prefix with a long name.)

Changed in inkscape:
assignee: nobody → Michael Wybrow (mjwybrow)
status: New → In Progress
su_v (suv-lp) wrote :

Thank you for the fix and the clarification regarding DYLD_LIBRARY_PATH!

Michael Wybrow (mjwybrow) wrote :

This is fixed in Inkscape-0.47-pre1-2.LEOPARD.dmg, which is on Sourceforge now.

Changed in inkscape:
status: In Progress → Fix Released
su_v (suv-lp) wrote :

The same conflicts happens with Inkscape 0.46-3 Tiger on OS X 10.4.11 if fontconfig is installed via MacPorts (see bug #183322 comments 7-14). Modifying 'fonts.conf' as described in comment 4 fixes the issue.

Michael Wybrow (mjwybrow) wrote :

This is properly fixed in the Inkscape-0.47pre2-1.LEOPARD.dmg, up now on sourceforge -- the official package no longer uses the DYLD_LIBRARY_PATH magic. Instead all paths within the dylibs, executable and shared objects get rewritten to be relative to the executable during the packaging process.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers