GNOME Bugzilla – Bug 529336
libtool 2 breaks gtk+ build
Last modified: 2010-09-19 05:09:30 UTC
I know that GTK+ currently demands libtool 1.4 or 1.5, but at some point libtool 2.x (currently 2.2.2) will replace 1.x, and the GTK+ build system will break. Currently the configure script runs libtool during it's execution: pixbuf_libtool_config="${CONFIG_SHELL-/bin/sh} ./libtool --config" With libtool 2.x, the libtool script isn't created until *after* the configure script has been executed, so this won't work.
Created attachment 109676 [details] [review] Patch to remove one libtool call This patch removes one of the libtool calls, as libtool.m4 initialises $deplibs_check_method for you there is no need to set it by calling libtool. The same logic can probably be applied to the other invocations, but I want to check them carefully.
Hm this patch may not work for libtool 1.5. It does for me, but it's not documented to work, so this is probably best left for a future 2.2 port.
I've been corrected on the libtool list, with libtool 1.4 onwards you can check the value of any libtool variable directly, so this patch is safe for libtool 1.4.
Does anyone know what this is all about: dnl Now we check to see if our libtool supports shared lib deps dnl (in a rather ugly way even) if $dynworks; then pixbuf_libtool_config="${CONFIG_SHELL-/bin/sh} ./libtool --config" pixbuf_deplibs_check=`$pixbuf_libtool_config | \ grep '^[[a-z_]]*check[[a-z_]]*_method=[['\''"]]' | \ sed 's/.*[['\''"]]\(.*\)[['\''"]]$/\1/'` if test "x$pixbuf_deplibs_check" = "xnone" || \ test "x$pixbuf_deplibs_check" = "xunknown" || \ test "x$pixbuf_deplibs_check" = "x"; then dynworks=false fi fi The only line in the output which matches for me is deplibs_check_method: deplibs_check_method="" So why doesn't GTK+ just check $deplibs_check_method with a case statement?
Created attachment 109697 [details] [review] Revised patch Considering the weird grep/sed logic is over 6 years old, I'm pretty certain it's cruft. This patch just checks $deplibs_check_method. If it isn't cruft, people will start moaning because they suddenly have no pixbuf loaders. :)
No idea at this point ... I suspect I copied that code from elsewhere... likely the standalone gdk-pixbuf... the usage of CONFIG_SHELL etc doesn't look like me. (Note that the first use of deplibs_check_method is several years newer than the second more complicated version... this is obscured by some reformatting.) This definitely needs careful testing, since if either test breaks the result won't be "no pixbuf loaders", it will be "subtle broken builds that cause ABI problems in the future."
I'm curious as to how this leads to ABI breakages. When these tests failed for us (due to libtool 2.2 being used) the primary damage was no modules. I've verified that for my system the patches produce the same results, but what would the potential ABI breakages be so I can check for them?
Gentoo has been dealing with libtool 2.2.x breakage for a while now. gtk+ versions up to 2.12.10 in Portage build successfully with 2.2.x. You might want to query the Gentoo Gnome herd on the details, gnome@gentoo.org. I can attach the obvious patch that's used, but there may be more to it than this one patch.
Created attachment 112763 [details] [review] Gentoo libtool patch for 2.12.9 and later
As of 2.13.5, gtk+ now builds with libtool 2.2.4 -- thanks very much! Now I can finally get back to testing Gnome 2.23 packages, something I've missed.
Created attachment 115190 [details] [review] Allow libtool 2.x in autogen.sh What about the autogen.sh script? I suspect it should not abort if libtool is something else than 1.4 or 1.5 anymore. This patch therefore allows for 2.x versions.
The same is valid for glib as well btw, the required change is the same. Not sure if there was a separate bug about that.
That's why I changed Pango to simply use gnome-autogen.sh.
(In reply to comment #13) > That's why I changed Pango to simply use gnome-autogen.sh. Which actually is a way of moving gtk towards gnometk, since suddenly you need an extra gnome package that you don't normally need to build it.
(In reply to comment #14) > (In reply to comment #13) > > That's why I changed Pango to simply use gnome-autogen.sh. > > Which actually is a way of moving gtk towards gnometk, since suddenly you need > an extra gnome package that you don't normally need to build it. Not to build it, to bootstrap it. You already need that for Pango, if you didn't notice...
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > That's why I changed Pango to simply use gnome-autogen.sh. > > > > Which actually is a way of moving gtk towards gnometk, since suddenly you need > > an extra gnome package that you don't normally need to build it. > > Not to build it, to bootstrap it. You already need that for Pango, if you > didn't notice... In fact I rarely need to build Pango from svn, since I'm only working on Gtk and Glib, so apparently I did not notice. Anyway, it's just my opinion that libraries that are independant from Gnome should try to avoid hard dependencies there, be it bootstrap or building. For me boostrap is part of the build requirements if I'm working with trunk and I don't have a Gnome install everywhere.
*** Bug 525934 has been marked as a duplicate of this bug. ***
We require libtool 2.2 in autogen.sh nowadays