GNOME Bugzilla – Bug 564018
pygobject libtool-2.2 patch
Last modified: 2009-01-07 00:50:14 UTC
I'm attaching a patch for libtool-2.2 compatibility, based on the solution in gtk+-2.14.
Created attachment 124369 [details] [review] libtool-2.2 patch
I admit I don't really understand it, but applied the patch in trunk. Seems to do nothing (bad or good) here, as expected. 2009-01-04 Paul Pogonyshev <pogonyshev@gmx.net> Bug 564018 – pygobject libtool-2.2 patch * configure.ac: Apply the patch provided by Cygwin Ports maintainer.
Just some feedback here: 1. The patch didn't make it into the 2.16.0 release. 2. Without the patch, building pygobject-2.16.0 on my OS X 10.4/ppc via 'autoreconf -fi && ./configure && make' with installed libtool-1.5.26 (not libtool2) installed fails badly: [...] checking whether to enable threading in pygobject... yes ./configure: line 1: ./libtool: No such file or directory checking for pkg-config... /sw/bin/pkg-config [...] /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I/sw/include/python2.6 -I/sw/include/python2.6 -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include -DPY_SSIZE_T_CLEAN -I/sw/include -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include -g -O2 -Wall -fno-strict-aliasing -std=c9x -c -o libpyglib_2_0_la-pyglib.lo `test -f 'pyglib.c' || echo './'`pyglib.c ../libtool: line 1: X--tag=CC: command not found [and a ton more errors indicating misconfiguration of the ./libtool script] 3. With the patch, ./configure in #2 above works fine. However, make still fails the same way. 4. Updating installed libtool to 2.2.6 (and with the patch applied), make also gets beyond that libtool crash. I suspect the 2.16.0 distro was rolled on a machine with libtool2?
(In reply to comment #3) > 1. The patch didn't make it into the 2.16.0 release. Yes, as I said I applied it in the trunk. Don't like changes I don't understand in stable branches ;) If you think it's worth it, I can apply in the branch too, though I doubt there will ever be 2.16.1. > 2. Without the patch, building pygobject-2.16.0 on my OS X 10.4/ppc via > 'autoreconf -fi && ./configure && make' with installed libtool-1.5.26 (not > libtool2) installed fails badly [...] > > 3. With the patch, ./configure in #2 above works fine. However, make still > fails the same way. > > 4. Updating installed libtool to 2.2.6 (and with the patch applied), make also > gets beyond that libtool crash. What was the libtool version before upgrading? > I suspect the 2.16.0 distro was rolled on a machine with libtool2? No idea. I was under the impression this patch was needed for non-GNU/Linux machines only, no?
Since the relevant ChangeLog in gtk+ (from where I borrowed this solution) isn't very descriptive, let me explain: With lt-1.x, AC_PROG_LIBTOOL would generate the build-tree libtool script immediately, meaning that any point thereafter one could call ./libtool for various tests (AFAIK this was originally the only way to get the libtool configuration info; this has changed since.) With lt-2.2, the default behaviour of LT_INIT (to which AC_PROG_LIBTOOL is now an alias) is to create the build-tree libtool during AC_OUTPUT. If you really need ./libtool earlier, then you call the new LT_OUTPUT macro. The problem with this scenario is compatibility with 1.x and 2.2 simultaneously, as both versions are still widely used. The patch uses m4_ifdef to detect if 2.2 is being used by the presence (or lack thereof) of LT_OUTPUT, and calls it if present; systems using 1.x aren't affected. Re: comment 3, that error looks like a classic libtool version mismatch. If you are running autoreconf (and for Darwin that's probably a good idea), make sure that libtool is replacing ltmain.sh as well as aclocal pulling in the matching system libtool macro(s). There's no reason it shouldn't build with 1.5.