GNOME Bugzilla – Bug 689282
'make check' fails when system glib is older than 2.34
Last modified: 2013-01-01 15:21:10 UTC
Created attachment 230189 [details] [review] Suggested patch (As asked, this happens on Linux (Exherbo) 3.6.5, libtool 2.4.2, pkg-config 0.27.1) After building using the provided 'autogen.sh' (so no configure options) and doing 'make check' I get this (I can provide the full log, if it interests anyone): TEST: unix-nothreads... (pid=32151) /glib-unix/pipe: OK /glib-unix/error: OK /glib-unix/sighup: OK /glib-unix/sigterm: OK /glib-unix/sighup_again: OK /glib-unix/sighup_add_remove: OK PASS: unix-nothreads TEST: include... (pid=32166) PASS: include make[4]: Leaving directory `/home/vinicius/work/glib/glib/tests' make[3]: Leaving directory `/home/vinicius/work/glib/glib/tests' make[2]: Leaving directory `/home/vinicius/work/glib/glib' make[1]: Leaving directory `/home/vinicius/work/glib/glib' Making check in gmodule make[1]: Entering directory `/home/vinicius/work/glib/gmodule' make check-am make[2]: Entering directory `/home/vinicius/work/glib/gmodule' make check-local make[3]: Entering directory `/home/vinicius/work/glib/gmodule' make[3]: Leaving directory `/home/vinicius/work/glib/gmodule' make[2]: Leaving directory `/home/vinicius/work/glib/gmodule' make[1]: Leaving directory `/home/vinicius/work/glib/gmodule' Making check in gthread make[1]: Entering directory `/home/vinicius/work/glib/gthread' make check-local make[2]: Entering directory `/home/vinicius/work/glib/gthread' make[2]: Leaving directory `/home/vinicius/work/glib/gthread' make[1]: Leaving directory `/home/vinicius/work/glib/gthread' Making check in gobject make[1]: Entering directory `/home/vinicius/work/glib/gobject' make check-recursive make[2]: Entering directory `/home/vinicius/work/glib/gobject' Making check in . make[3]: Entering directory `/home/vinicius/work/glib/gobject' make check-TESTS check-local make[4]: Entering directory `/home/vinicius/work/glib/gobject' PASS: abicheck.sh ============= 1 test passed ============= make[4]: Leaving directory `/home/vinicius/work/glib/gobject' make[3]: Leaving directory `/home/vinicius/work/glib/gobject' Making check in tests make[3]: Entering directory `/home/vinicius/work/glib/gobject/tests' make check-am make[4]: Entering directory `/home/vinicius/work/glib/gobject/tests' make check-local make[5]: Entering directory `/home/vinicius/work/glib/gobject/tests' TEST: qdata... (pid=32238) /qdata/threaded: /home/vinicius/work/glib/gobject/tests/.libs/qdata: symbol lookup error: /home/vinicius/work/glib/gobject/tests/.libs/qdata/home/vinicius/work/glib/gobject/tests/.libs/qdata/home/vinicius/work/glib/gobject/.libs/libgobject-2.0.so.0: : symbol lookup errorundefined symbol: g_datalist_id_replace_data: : /home/vinicius/work/glib/gobject/tests/.libs/qdatasymbol lookup error: : symbol lookup error/home/vinicius/work/glib/gobject/.libs/libgobject-2.0.so.0: : /home/vinicius/work/glib/gobject/.libs/libgobject-2.0.so.0undefined symbol: g_datalist_id_replace_data: /home/vinicius/work/glib/gobject/tests/.libs/qdata: undefined symbol: g_datalist_id_replace_data symbol lookup error FAIL GTester: last random seed: R02S9acf36825a112caaefdeeccd17d76a6c /bin/sh: line 1: 32224 Terminated G_DEBUG=gc-friendly MALLOC_CHECK_=2 MALLOC_PERTURB_=$((${RANDOM:-256} % 256)) ../../glib/gtester --verbose qdata boxed enums param signals threadtests dynamictests binding properties reference ifaceproperties valuearray make[5]: *** [test-nonrecursive] Error 143 Grep'ing for LD_LIBRARY_PATH on gobject/tests/qdata gives this: $ grep 'LD_LIBRARY_PATH=' gobject/tests/qdata LD_LIBRARY_PATH="/home/vinicius/work/glib/gobject/.libs:/usr/lib64:/home/vinicius/work/glib/gthread/.libs:/home/vinicius/work/glib/glib/.libs:$LD_LIBRARY_PATH" LD_LIBRARY_PATH=`$ECHO "$LD_LIBRARY_PATH" | /bin/sed 's/::*$//'` The same happens for every executable inside 'gobject/tests'. So everything points to something in the building of the tests. Taking a look at the pkg-config files of libgobject, libgthread and libglib, the only one that adds a specific dependence of something in '/usr/lib64' is libgobject. And moving it to end of the dependence list seemed to solve the problem. Suggested patch attached.
What's in your libffi.pc? Do you have a /usr/lib64/libffi.la? What does 'pkg-config --libs libffi' say? Where did you get your libffi and your pkg-config? From Exherbo packages, or from a third party? Where does Exherbo normally install "system" packages? (/usr/lib64?) I think the bug here might be that 'pkg-config --libs libffi' is returning -L/usr/lib64, which shouldn't be necessary, because /usr/lib64 should already be on the compiler's default search path. pkg-config has logic to filter out -L flags corresponding to default library directories. Or, there might be a corresponding bug in your libtool. The fixed bug <https://bugs.freedesktop.org/show_bug.cgi?id=16095> in pkg-config is related; I added a --with-system-library-path configure option to pkg-config, but it defaults to /usr/lib64:/usr/lib if your ${libdir} ends with lib64, so that should do the right thing. What configure options does Exherbo use for their pkg-config?
I'm pretty sure this happens when you have .la files in the system library paths. I have no objections to taking patches to make GLib compilation defensive against this scenario, but really - fix Exherbo to delete .la files from system paths: http://wiki.debian.org/ReleaseGoals/LAFileRemoval http://fedoraproject.org/wiki/Packaging:Guidelines ("Libtool archives, foo.la files, should not be included. ")
This sort of breakage can also be caused by rpath in weird situations (like jhbuild)...
(In reply to comment #1) > What's in your libffi.pc? > prefix=/usr exec_prefix=${prefix} libdir=/usr/lib64 includedir=${libdir}/libffi-3.0.11/include Name: libffi Description: Library supporting Foreign Function Interfaces Version: 3.0.11 Libs: -L${libdir} -lffi Cflags: -I${includedir} > Do you have a /usr/lib64/libffi.la? Yes. And if I remove it, it works. > > What does 'pkg-config --libs libffi' say? -lffi > > Where did you get your libffi and your pkg-config? From Exherbo packages, or > from a third party? From Exherbo. > > Where does Exherbo normally install "system" packages? (/usr/lib64?) Yes, /usr/lib64 in my case, running an amd64 system. > > I think the bug here might be that 'pkg-config --libs libffi' is returning > -L/usr/lib64, which shouldn't be necessary, because /usr/lib64 should already > be on the compiler's default search path. pkg-config has logic to filter out -L > flags corresponding to default library directories. > > Or, there might be a corresponding bug in your libtool. > > The fixed bug <https://bugs.freedesktop.org/show_bug.cgi?id=16095> in > pkg-config is related; I added a --with-system-library-path configure option to > pkg-config, but it defaults to /usr/lib64:/usr/lib if your ${libdir} ends with > lib64, so that should do the right thing. What configure options does Exherbo > use for their pkg-config? Only --disable-static and --without-internal-glib . So if I can read this right, this points to a problem in libtool, right?
(In reply to comment #4) > > Do you have a /usr/lib64/libffi.la? > > Yes. And if I remove it, it works. There's the problem, then... > > Where did you get your libffi and your pkg-config? From Exherbo packages, or > > from a third party? > > From Exherbo. > > > > > Where does Exherbo normally install "system" packages? (/usr/lib64?) > > Yes, /usr/lib64 in my case, running an amd64 system. ... .la files in "system" directories (those searched by default by the linker) are problematic for various reasons, and most major distributions remove them[1][2][3][4]. If Exherbo doesn't, it probably should. If Exherbo is a binary distribution like Fedora and Debian, that will have to be a gradual process, because it has to be done in dependency order (e.g. Clutter-Gtk before Gtk before GLib); if it's a source distribution like Gentoo, it doesn't have to be done in strict dependency order, if I understand correctly. [1] http://wiki.debian.org/ReleaseGoals/LAFileRemoval [2] https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries [3] http://en.opensuse.org/openSUSE:Packaging_guidelines#Static_Libraries [4] https://blog.flameeyes.eu/2008/07/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later etc.
I don't think there is anything for us to do here. libtool...