GNOME Bugzilla – Bug 709583
gobject-introspection: improve compatibility on OS X
Last modified: 2015-02-07 16:48:59 UTC
Created attachment 256649 [details] [review] patch against giscanner/shlib.py While gobject-introspection works on OS X, a few circumstances are handled a little different there. For one, libraries are linked using absolute paths. The current gobject-introspection code however strips any path components and just uses the filename in the .gir file – while this doesn't cause failure, the generated typlibs will only work in presence of a correctly set DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH environment variable. Setting DYLD_LIBRARY_PATH on OS X often is a bad idea due to the side-effects: Doing so causes the directory parts of libraries referenced using an absolute path to be ignored if there is a equally named file in the directory listed in $DYLD_LIBRARY_PATH, possibly overriding referenced system libraries with incompatible versions. Setting DYLD_FALLBACK_LIBRARY_PATH is the better solution for this problem; however because this variable has an implicit default value it's not simple to do so correctly. The best solution to the problem is referencing libraries from .girs using absolute paths, just as all other binaries on OS X. The attached patches against 2.38.0 implement that. Another quirk one needs to be aware of on OS X is that Apple ships a program called libtool, which is not GNU libtool and incompatible with it. GNU libtool, if present, is usually called glibtool on OS X. The patches also fix this. Variants of these patches have been rolled out in MacPorts' copy of gobject-introspection for 15 months now; they should be fairly stable. Btw: While somebody's at it, the patch provided in comment 9 of #631507 has also been in MacPorts for a while and should probably be committed.
Created attachment 256650 [details] [review] patch against giscanner/utils.py
Any progress on this? I'd really like to discontinue patching this downstream for each gobject-introspection release…
Review of attachment 256650 [details] [review]: ::: utils.py.org @@ +152,3 @@ + if platform.system() == 'Darwin': + # libtool on OS X is a completely different program written by Apple + libtool_cmd = 'glibtool' I have one minor concern about this - if g-i is used in an environment like Homebrew, is it possible that libtool will once again be GNU Libtool? Oh well, we can deal with that if it happens.
No: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/libtool.rb#L4. It is possible for users to do this manually, but the package managers out there don't.
Review of attachment 256649 [details] [review]: I'm not an OS X expert, but your analysis looks on the surface sound. Thanks for writing such a complete commit message with rationale! That type of thing is very useful for people who need to debug something later.
https://git.gnome.org/browse/gobject-introspection/commit/?id=513dfb969c2317377eb0f0ec150767a8d95c6d2e
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]