GNOME Bugzilla – Bug 712314
[2.39.1] AIX port: splice(); major()/minor(); libtool library order
Last modified: 2013-11-19 13:13:19 UTC
Three problems building glib-2.39.1 on AIX: CC libgio_2_0_la-gfile.lo gfile.c:2871:12: error: unknown type name 'loff_t' ... This is because AIX does provide splice(), but with different signature than expected, not declaring some loff_t type at all: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.commtechref/doc/commtrf2/splice.htm Workaround is to configure with ac_cv_func_splice=no environment variable preset. CC libgio_2_0_la-gdbusmessage.lo gdbusmessage.c: In function 'g_dbus_message_print': gdbusmessage.c:3466:43: error: implicit declaration of function 'major' [-Werror=implicit-function-declaration] gdbusmessage.c:3466:43: error: implicit declaration of function 'minor' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors Actually, sys/types.h would define them when _BSD is defined, but there already is an autoconf check for major(), minor(), makedev(): AC_HEADER_MAJOR http://www.gnu.org/software/autoconf/manual/autoconf.html#AC_005fHEADER_005fMAJOR CCLD glib-compile-resources ld: 0711-317 ERROR: Undefined symbol: .g_subprocess_new ld: 0711-317 ERROR: Undefined symbol: .g_subprocess_wait_check ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. Problem here is that there is glib-2.34.3 is preinstalled in /opt/freeware/ besides the compiler used. The lt-library order given to libtool when linking glib-compile-resources is: 1) ../glib/libglib-2.0.la (referring to /opt/freeware/lib/lib{intl,iconv}.la) 2) ../gobject/libgobject-2.0.la 3) libgio-2.0.la Because of this, libtool library search encounters /opt/freeware/lib/libgio-2.0.* before local libgio-2.0.la.
Created attachment 259821 [details] [review] Patch to disable using splice() on AIX (git master)
Created attachment 259822 [details] [review] Patch to use AC_HEADER_MAJOR autoconf macro (git master)
Created attachment 259823 [details] [review] Patch to fix library order passed to libtool (git master).
Review of attachment 259821 [details] [review]: Ok.
Review of attachment 259822 [details] [review]: Ok. Looks like this is in at least the RHEL6 version of autoconf, so fine by me.
(In reply to comment #0) > > Problem here is that there is glib-2.34.3 is preinstalled in /opt/freeware/ > besides the compiler used. The lt-library order given to libtool when linking > glib-compile-resources is: > 1) ../glib/libglib-2.0.la (referring to /opt/freeware/lib/lib{intl,iconv}.la) > 2) ../gobject/libgobject-2.0.la > 3) libgio-2.0.la > > Because of this, libtool library search encounters > /opt/freeware/lib/libgio-2.0.* before local libgio-2.0.la. That's really a libtool flaw though, which you can work around by deleting the .la files from your buildroot. Some more information here: https://wiki.gnome.org/GnomeShell/RemovingLaFiles All build systems I work on (jhbuild, rpm, gnome-continuous) all purge .la files from the buildroot for this reason. So practically speaking, while I don't object to this patch, you are going to be constantly battling this issue, and the path of least resistance really will be deleting the .la files.
(In reply to comment #6) While I basically agree, the problem here is that I do not necessarily have (root) access to delete /opt/freeware/lib/lib*.la. Also, sometimes it might be necessary to link statically, where .la files are required to resolve dependencies. And even without .la files, on some platforms static linking requires passing the .a files either in correct order or multiple times, to allow the linker to resolve all the symbols. So when it is as easy as accepting simple enough patches to get the library ordering right even with .la files, I'd very much appreciate such patches to be accepted - while leaving the battle itself to those users that have to deal with it. Thank you!
Review of attachment 259823 [details] [review]: Ok, so this patch is merely reordering the glib-internal libraries; most often, putting gio-2.0.la before glib-2.0.la. Which should be completely harmless in most cases, and should help you. It's fairly unfortunate that we can't tell libtool that if we're linking libgio-2.0.la, we *always* want libglib-2.0.la. We achieve this via pkg-config for external consumers, but it'd require backflips to use it for our internal build. I'm OK with this, but like I said, you will likely end up fixing it up continually since few other contributors are in this situation.