GNOME Bugzilla – Bug 357209
"pango" builds modules incorrecty under Mac OS X (Darwin)
Last modified: 2006-09-22 21:31:53 UTC
Steps to reproduce: 1. Compile unpatched "pango". 2. Run "pango-querymodules". Stack trace: Other information: The problem is that the build framework assumes that shared libraries and object use the same extension e.g. ".so". This is *not* true under Mac OS X. Shared libraries are called somehting like "libfoobar.1.2.3.dylib" while shared objects are called "foobar.so".
Created attachment 73218 [details] [review] Patch from NetBSD's pkgsrc which corrects the problem
You should fix glib to declare the correct G_MODULE_SUFFIX.
*** Bug 357210 has been marked as a duplicate of this bug. ***
I'm confused. Why do you think pango/gdk-pixbuf look for .dylib in the first place? Checking glib/configure.in, gmodule will use .so on darwin. In any case, you should patch glib/configure.in (search for ltconfig).
What is G_MODULE_SUFFIX defined to in <libdir>/glib/include/glibconfig.h, and what is the output of: libtool --config | grep shrext_cmds
> /usr/pkg/bin/libtool --config | grep shrext_cmds shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'
And the value of G_MODULE_SUFFIX?
> grep G_MODULE_SUFFIX /usr/pkg/lib/glib-2.0/include/glibconfig.h #define G_MODULE_SUFFIX "so"
(In reply to comment #8) > > grep G_MODULE_SUFFIX /usr/pkg/lib/glib-2.0/include/glibconfig.h > #define G_MODULE_SUFFIX "so" Then the problem is not as you describe. Pango and gdk-pixbuf /are/ looking for .so modules. What is the symptom of the problem?
The system was (the last time I checked without the suggested patch) that "pango-querymodules" was looking for modules ending with ".so" but all the installed modules ended on ".dylib" and were not found. As a result "pango-querymodules" return an error code and building anything which used "pango" (e.g. "gtk+") failed. This is the reason why I assumed that "pango" is causing the bug. The module loader in "glib" is apparently doing the right thing, but the "pango" build framework does not.
This is just speculation, but maybe there was a libtool change and the descrepancy is due to glib and pango shipping different versions of libtool?
Ah ok, so by saying """Shared libraries are called somehting like "libfoobar.1.2.3.dylib" while shared objects are called "foobar.so".""" I thought you mean modules should use .so but shared libraries use .dylib. Now you are saying that it is the other way. Right? "libfoobar.1.2.3.so" and "foobar.dylib". In that case, it is indeed glib's fault. Check out glib/configure.in, search for ltconfig. Add your case there. Glib indeed should be fixed to either update to the latest libtool stuff, or better, use libtool --config instead of hardcoding its own switch. However, it's not quite easy to call libtool from configure. Or is it?
NetBSD's pkgsrc *never* uses the bundled "libtool" mostly because 99.99% of "libtool" versions don't work under anything except Linux-i386. It uses a carefully configured and patched version which is part of "pkgsrc" and is used for all packages. And no, that "libtool" version is not to blame because it works fine for other packages which build modules (e.g. "gimp"). Back to the original problem: I've just rebuilt the "pango" package without the suggested patches and the modules where correctly named. I therefore assume that the problem has been fixed in the meantime. I'm currently building the "gtk+" to test whether it works now, too.
To clarify the naming scheme: Shared library are called "lib*.dylib" under Mac OS X e.g.: -r-xr-xr-x 1 root wheel 4379472 Sep 18 22:06 /usr/lib/libSystem.B.dylib That's Mac OS X's equivalent of "libc". Shared objects are called "*.so" under Mac OS X e.g.: -r--r--r-- 1 root wheel 9384 Jun 23 18:44 /usr/lib/pam/pam_afpmount.so -rwxr-xr-x 1 root wheel 8392 Jan 30 2006 /usr/lib/pam/pam_deny.so -r--r--r-- 1 root wheel 18456 Feb 27 2006 /usr/lib/pam/pam_netinfo.so -rwxr-xr-x 1 root wheel 8560 Jan 30 2006 /usr/lib/pam/pam_nologin.so -rwxr-xr-x 1 root wheel 8476 Jan 30 2006 /usr/lib/pam/pam_permit.so -rwxr-xr-x 1 root wheel 8452 Jan 30 2006 /usr/lib/pam/pam_rootok.so -rwxr-xr-x 1 root wheel 8748 Jan 30 2006 /usr/lib/pam/pam_securetty.so -r--r--r-- 1 root wheel 8620 Feb 27 2006 /usr/lib/pam/pam_securityserver.so -r--r--r-- 1 root wheel 8732 Feb 27 2006 /usr/lib/pam/pam_unix.so -r--r--r-- 1 root wheel 8492 Feb 27 2006 /usr/lib/pam/pam_uwtmp.so -rwxr-xr-x 1 root wheel 8900 Jan 30 2006 /usr/lib/pam/pam_wheel.so If "glib" uses the above scheme it is correct.
(In reply to comment #14) > If "glib" uses the above scheme it is correct. It does. And that's why I'm confused. Now that you mention, I remember .dylib was introduced in glib for darwin and withdrawn later. That is between versions 2.10.1 and fixed in 2.10.2. So, yes, it's been fixed in the mean time.
Building the "gtk+" version 2.10.3 without the suggested patch. Building "xchat" using that GTK+ library succeeds without problems, too, which proves that "gdk-pixbuf-query-loaders" work fine. It's seems that the problem which made those patches necessary has been addressed in the meantime. I'm sorry that I neither submitted this bug in a timely fashion nor tested it.