After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 606686 - [build] Mac OS X support
[build] Mac OS X support
Status: RESOLVED FIXED
Product: gobject-introspection
Classification: Platform
Component: general
2.23.x
Other Mac OS
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
: 587641 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-01-11 23:24 UTC by John Ralls
Modified: 2015-02-07 16:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Do not include preprocessor flags into GLib_2_0_gir_CFLAGS (808 bytes, patch)
2010-06-04 11:07 UTC, Alexey Zakhlestin
committed Details | Review
use "otool -L" instead of "ldd" on Darwin (1.02 KB, patch)
2010-06-04 11:08 UTC, Alexey Zakhlestin
committed Details | Review
choose shared library extension depending on OS (1.21 KB, patch)
2010-10-06 10:55 UTC, Alexey Zakhlestin
reviewed Details | Review
choose shared library extension depending on OS (1.21 KB, patch)
2010-10-06 11:28 UTC, Alexey Zakhlestin
none Details | Review

Description John Ralls 2010-01-11 23:24:01 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
Comment 1 Johan (not receiving bugmail) Dahlin 2010-04-07 16:39:29 UTC
The introspection dumper program needs to be ported to osx. otool should be used instead of ldd.
Comment 2 Daniel Macks 2010-04-29 19:00:30 UTC
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)?
Comment 3 Daniel Macks 2010-04-30 00:56:04 UTC
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?
Comment 4 Alexey Zakhlestin 2010-06-04 11:07:26 UTC
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
Comment 5 Alexey Zakhlestin 2010-06-04 11:08:58 UTC
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
Comment 6 Johan (not receiving bugmail) Dahlin 2010-06-04 12:50:29 UTC
Thanks for the patches Alexey, they were both committed. 
I'm still keeping this bug open until the gir dynlib filenames are properly fixed.
Comment 7 Johan (not receiving bugmail) Dahlin 2010-06-04 12:51:34 UTC
*** Bug 587641 has been marked as a duplicate of this bug. ***
Comment 8 Daniel Macks 2010-06-04 17:03:07 UTC
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.
Comment 9 Alexey Zakhlestin 2010-10-06 10:55:01 UTC
Created attachment 171819 [details] [review]
choose shared library extension depending on OS
Comment 10 Johan (not receiving bugmail) Dahlin 2010-10-06 11:08:12 UTC
Review of attachment 171819 [details] [review]:

Rest looks good

::: giscanner/libtoolimporter.py
@@ +22,3 @@
 import os
 import sys
+import platform

Keep it ordered alphabetically
Comment 11 Alexey Zakhlestin 2010-10-06 11:28:17 UTC
Created attachment 171821 [details] [review]
choose shared library extension depending on OS
Comment 12 John Ralls 2010-10-06 13:46:03 UTC
Is this for loadable modules (linked with dlopen) or for dynamic libraries (linked at program startup)?
Comment 13 Alexey Zakhlestin 2010-10-06 13:58:05 UTC
It is for loading dynamic libraries with dlopen during runtime ;)
Comment 14 John Ralls 2010-10-06 14:17:05 UTC
Then it's wrong. Libtool uses .so for loadable modules on Darwin, though Darwin's loader will cheerfully accept either file extension.
Comment 15 Alexey Zakhlestin 2010-10-06 14:37:19 UTC
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.
Comment 16 John Ralls 2010-10-06 23:39:25 UTC
Ah, I see.
Comment 17 André Klapper 2015-02-07 16:53:25 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]