GNOME Bugzilla – Bug 606686
[build] Mac OS X support
Last modified: 2015-02-07 16:53:25 UTC
Building gobject-introspection master fails on OSX with the following configuration and errors: ./configure --enable-maintainer-mode --prefix /usr/local/gtk-unstable/inst --libdir /usr/local/gtk-unstable/inst/lib --disable-static *** Building gobject-introspection *** [1/1] make make all-recursive Making all in girepository make[2]: Nothing to be done for `all'. Making all in giscanner make all-am make[3]: Nothing to be done for `all-am'. Making all in tools GEN g-ir-scanner Making all in gir GISCAN GLib-2.0.gir ../libtool: line 8858: exec: ldd: not found ERROR: can't resolve libraries to shared libraries: glib-2.0 make[2]: *** [GLib-2.0.gir] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Here's the detailed output from make V=1: make[2]: Nothing to be done for `all'. Making all in gir env LPATH=.libs env PYTHONPATH=..:..:YTHONPATH UNINSTALLED_INTROSPECTION_SRCDIR=.. UNINSTALLED_INTROSPECTION_BUILDDIR=.. ../tools/g-ir-scanner -v --add-include-path=../gir --add-include-path=. -v --add-include-path=../gir --add-include-path=. --namespace=GLib --nsversion=2.0 --libtool="/bin/sh ../libtool" --library=glib-2.0 --pkg=glib-2.0 --noclosure --strip-prefix=g --c-include="glib.h" -I/usr/local/gtk-unstable/inst/include -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -I/usr/local/gtk-unstable/inst/include/glib-2.0 -I/usr/local/gtk-unstable/inst/lib/glib-2.0/include -DGETTEXT_PACKAGE=Dummy -DGLIB_COMPILATION -D__G_I18N_LIB_H__ /usr/local/gtk-unstable/inst/lib/glib-2.0/include/glibconfig.h /usr/local/gtk-unstable/inst/include/glib-2.0/glib/*.h ./glib-2.0.c --output GLib-2.0.gir ../libtool: line 8858: exec: ldd: not found ERROR: can't resolve libraries to shared libraries: glib-2.0
The introspection dumper program needs to be ported to osx. otool should be used instead of ldd.
Could someone give some clearer documentation about exactly what form the passed parameters are in giscanner/shlibs.py? I know how to use otool -L to get dynamic-linker data, but I don't understand what specific format the dumper wants to have that data. Working backwards through that file... resolve_shlibs(options, binary, libraries) I assume "binary" is a path to the compiled program whose dynamic-linking we want to read. Is "libraries" is the list of ("<foo> of -l<foo>" per embedded comment), or is it a list of .la and .so (or maybe even arbitrary other compiled binary programs?) actual filenames (since we seem to filter it by that sort of pattern) that are already known...somehow? Is the intended return value to be a list of full paths to shared libraries (sonames) of the libfoo linked by the binary (/usr/lib/libpangoft2-1.0.so.0)?
Alright, I did some voodoo debugging, and just changing 'ldd' to 'otool','-L' in giscanner/shlibs.py makes something that works and passes the -expected.{gir,tgir} self-tests once I changed those files to refer to the libraries as .dylib instead of .so. To make portable, need to have shlibs.py choose the command based on...some python variable that indicates the platform. And need to maybe have all the -expected.{gir,tgir} be supplied as .in templates that get processed during ./configure to use the platform-correct extension. The later tests still fail though, with "obviously wrong" things like dlopen(libgio-2.0.0.dylib.dylib, 9). Somehow the logic that decides how to build the actual filename is probably hardcoded to "trim .so, add platform-extension"? Or else something earlier is expecting to have truncated the file a certain way?
Created attachment 162742 [details] [review] Do not include preprocessor flags into GLib_2_0_gir_CFLAGS Attached patch, which excludes CPPFLAGS from GLib_2_0_gir_CFLAGS. GLib_2_0_gir_CFLAGS is used in g-ir-scanner parameters and is not compatible with various preprocessor flags. For example, Mac OS X's "homebrew" build-system uses such custom preprocessor flags and build without this patch fails
Created attachment 162743 [details] [review] use "otool -L" instead of "ldd" on Darwin This patch fixes original issue by implementing a Darwin-specific branch in giscanner/shlibs.py
Thanks for the patches Alexey, they were both committed. I'm still keeping this bug open until the gir dynlib filenames are properly fixed.
*** Bug 587641 has been marked as a duplicate of this bug. ***
Regarding Comment #4, cleaner to have -I and -D flags passed via FOO_CPPFLAGS rather than FOO_CFLAGS. That's probably the root of the problem being solved with that patch: FOO_CFLAGS goes to both the compile and link stages but -I and -D flags (and others that are traditionally passed via global CPPFLAGS) are only for the compiler. It's always annoying because it pollutes the linker call (more cruft makes it harder to debug the build), and now we have an example where it's an actual bug. So first, global CPPFLAGS is usually passed automatically by automake (*never* need to place it in a FOO_*FLAGS explicitly) and second cppflags don't really belong in CFLAGS. It's even more confusing because pkg-config publishes its compiler flags via BAR_CFLAGS even though that data is not for linker and so really should only go via FOO_CPPFLAGS in automake. I've got some patches laying around for that in g-ir, haven't bothered to clean it up because it's a minor point/more important g-ir concerns to deal with.
Created attachment 171819 [details] [review] choose shared library extension depending on OS
Review of attachment 171819 [details] [review]: Rest looks good ::: giscanner/libtoolimporter.py @@ +22,3 @@ import os import sys +import platform Keep it ordered alphabetically
Created attachment 171821 [details] [review] choose shared library extension depending on OS
Is this for loadable modules (linked with dlopen) or for dynamic libraries (linked at program startup)?
It is for loading dynamic libraries with dlopen during runtime ;)
Then it's wrong. Libtool uses .so for loadable modules on Darwin, though Darwin's loader will cheerfully accept either file extension.
John, we need to load regular dynamic libraries, which are built as ".dylib", not some specially-made ".so" modules. And it seems to work fine If you find a case where this change breaks things post a separate bug.
Ah, I see.
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]