Conflict between bundled and system libxml dylib

Bug #392693 reported by Wim Lewis on 2009-06-26
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Michael Wybrow

Bug Description

The pre-compiled Inkscape-0.46-2.LEOPARD.UNIVERSAL.dmg will not run on my system. The problem is that the included copy of libxml2 is an older version than the system version, which itself is indirectly used by inkscape:

Process: inkscape-bin [25867]
Path: /Applications/Local/
Code Type: X86 (Native)
Dyld Error Message:
  Library not loaded: /usr/lib/libxml2.2.dylib
  Referenced from: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
  Reason: Incompatible library version: DictionaryServices requires version 10.0.0 or later, but libxml2.2.dylib provides version 9.0.0

"otool -L" shows that is version 9.31.0, but /usr/lib/libxml2.2.dylib is 10.3.0.

Simply removing Inkscape's copy of libxml2.2.dylib caused it to load the system's copy instead and all was well.

As an aside, Inkscape's libraries all have install-names of /opt/local/lib, and Inkscape uses DYLD_LIBRARY_PATH to find them, which is probably not a good idea--- for bundled libraries, it's much less trouble-prone to use the @executable_path or (on 10.5 and up) @loader_path and @rpath features of dyld.

Bug #345176 is somewhat related but is a different problem.

Tags: osx Edit Tag help
Wim Lewis (wiml) on 2009-06-26
description: updated
su_v (suv-lp) wrote :

Could you test with a recent development build from <;O=D> if your problem still persists?

It might be helpful to know more about your system setup (version, any macports/fink installs, other) as both stable and dev builds seem to be running without your described problems on default OS X installs.

Michael Wybrow (mjwybrow) wrote :

This is an unfortunate consequence of using DYLD_LIBRARY_PATH, when Apple's system libraries have dependencies on libraries that might also be provided by Macports and bundled with Inkscape.

The right way to fix this is to further investigate and fix the problems with rewriting the install-names for all the libraries bundled with Inkscape, so that DYLD_LIBRARY_PATH is not required.

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

Adding two other libraries with compatibility conflicts:

1) libpng (bug #267053, duplicate bug #302460)
2) fontconfig (new):

Trying to help a user solve issues with LaTex support in Inkscape I got stuck today with incompatible libfontconfig.1.dylib versions - this time between Inkscape 0.47pre1-2 Leopard and a recently compiled 'pstoedit' helper application. Investigating and comparing 0.47pre1-2 from and a locally compiled Inkscape r22115 showed that fontconfig installed via Macports has bumped up the compatibility version from 5.0.0 to 6.0.0.

Does this means that any helper application a user compiles herself for Inkscape 0.47 which links to/loads the shared fontconfig library will not work when called from within the extension system unless either was built with the same MacPorts configuration or $DYLD_LIBRARY_PATH has been replaced by other means?

Inkscape 0.47pre1-2 r21720 (from
   /opt/local/lib/libfontconfig.1.dylib (compatibility version 5.0.0, current version 5.0.0)

Inkscape 0.46+devel r22115:
   /Volumes/blue/mp/lib/libfontconfig.1.dylib (compatibility version 6.0.0, current version 6.1.0)

pstoedit [pstoedit @3.45_3 (active)]
   /Volumes/blue/mp/lib/libfontconfig.1.dylib (compatibility version 6.0.0, current version 6.1.0)

libfontconfig.1.dylib [fontconfig @2.7.1_0+macosx (active)]
   /Volumes/blue/mp/lib/libfontconfig.1.dylib (compatibility version 6.0.0, current version 6.1.0)

Michael Wybrow (mjwybrow) wrote :

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.

The Inkscape-0.47pre2-1.LEOPARD.dmg up on sourceforge contains this fix.

Packagers will need to install Macports into a PREFIX of 50 characters in length to allow enough space within all the libraries for path rewriting.

Changed in inkscape:
status: Confirmed → Fix Released
ScislaC (scislac) wrote :


Not that I do packaging for Macs, must it be exactly 50 characters? Or did you mean 50 characters or less?

Michael Wybrow (mjwybrow) wrote :

I've put a test in the packaging script that makes sure it is 50 characters or more -- this is the requirement.

I know that "/opt/local/" was too short to always allow the rewriting of paths. It might not actually require 50 characters, but it is easier to just use that limit that try installing a complete new macports tree to test it for different path lengths. I'll add a note to the relevant page on the Wiki.

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

Other bug subscribers