GNOME Bugzilla – Bug 754690
libtool versions earlier than 2.4.4 fail with autoreconf
Last modified: 2015-10-20 13:50:47 UTC
I suspect I have some old version of something. I hadn't built gst-libav for a while. This is not due to cached files as it also happened with a fresh clone. autoconf (GNU Autoconf) 2.69 automake (GNU automake) 1.14.1 libtool (GNU libtool) 2.4.2 At least one of the missing configure flags passed to libav was removed in 2012, looking at git. So I'm not sure how this could build, which makes me think I might be doing something wrong here.
Created attachment 310834 [details] [review] add LT_INIT automake (from autogen.sh) would error out and ask for this. Submodule path 'gst-libs/ext/libav': checked out '15466db69e60f486c44e4c3e680d27c951f125d7' + passing argument --prefix=/home/v to configure + passing argument --disable-gtk-doc to configure + options passed to configure: --prefix=/home/v --disable-gtk-doc + check for build tools checking for autoreconf ... /home/v/bin/autoreconf checking for pkg-config ... /usr/bin/pkg-config configure.ac:69: installing './compile' configure.ac:11: installing './config.guess' configure.ac:11: installing './config.sub' configure.ac:14: installing './install-sh' configure.ac:14: installing './missing' Makefile.am: installing './INSTALL' ext/libav/Makefile.am:1: error: Libtool library used but 'LIBTOOL' is undefined ext/libav/Makefile.am:1: The usual way to define 'LIBTOOL' is to add 'LT_INIT' ext/libav/Makefile.am:1: to 'configure.ac' and run 'aclocal' and 'autoconf' again. ext/libav/Makefile.am:1: If 'LT_INIT' is in 'configure.ac', make sure ext/libav/Makefile.am:1: its definition is in aclocal's search path. ext/libav/Makefile.am: installing './depcomp' ext/libswscale/Makefile.am:1: error: Libtool library used but 'LIBTOOL' is undefined ext/libswscale/Makefile.am:1: The usual way to define 'LIBTOOL' is to add 'LT_INIT' ext/libswscale/Makefile.am:1: to 'configure.ac' and run 'aclocal' and 'autoconf' again. ext/libswscale/Makefile.am:1: If 'LT_INIT' is in 'configure.ac', make sure ext/libswscale/Makefile.am:1: its definition is in aclocal's search path. parallel-tests: installing './test-driver' autoreconf: automake failed with exit status: 1
Created attachment 310835 [details] [review] remove obsolete configuration flags ffmpeg was changed to another fork recently, this apparently did not get updated to go with it (but then it should not have built, it's puzzling).
I doubt the LT_INIT thing is correct, but no matter of re-autoconf/aclocal/automake/libtoolize would get it past this without it.
Comment on attachment 310834 [details] [review] add LT_INIT It's called by AS_LIBTOOL already, libtool just doesn't see that.
Comment on attachment 310835 [details] [review] remove obsolete configuration flags How are these failing for you? Works for me :) And --disable-iconv is definitely needed.
automake (GNU automake) 1.15 autoconf (GNU Autoconf) 2.69 libtool (GNU libtool) 2.4.2 here
(In reply to Sebastian Dröge (slomo) from comment #5) > Comment on attachment 310835 [details] [review] [review] > remove obsolete configuration flags > > How are these failing for you? Works for me :) > > And --disable-iconv is definitely needed. So... looks like if I take out the libtool bodge, I don't see that original issue anymore (I had that one before I got to the libtool one). And there is a --disable-postproc in configure. Very odd. I suspect something failed in my original git pull / configure which ended up with the wrong version of libav in gst-llibs/ext/libav... Which could explain the absence of all these flags in it. OK, nevermind then. Still won't build without LT_INIT though. Full log: v@euryale:~/src$ git clone git://anongit.freedesktop.org/gstreamer/gst-libav Cloning into 'gst-libav'... remote: Counting objects: 10886, done. remote: Compressing objects: 100% (6873/6873), done. remote: Total 10886 (delta 7347), reused 5529 (delta 3788) Receiving objects: 100% (10886/10886), 2.00 MiB | 365 KiB/s, done. Resolving deltas: 100% (7347/7347), done. v@euryale:~/src$ cd gst-libav v@euryale:~/src/gst-libav$ ./autogen.sh --prefix=$HOME --disable-gtk-doc + Setting up common submodule Submodule 'common' (git://anongit.freedesktop.org/gstreamer/common) registered for path 'common' Submodule 'gst-libs/ext/libav' (git://source.ffmpeg.org/ffmpeg.git) registered for path 'gst-libs/ext/libav' Cloning into 'common'... remote: Counting objects: 3804, done. remote: Compressing objects: 100% (2065/2065), done. remote: Total 3804 (delta 2563), reused 2564 (delta 1729) Receiving objects: 100% (3804/3804), 596.96 KiB | 338 KiB/s, done. Resolving deltas: 100% (2563/2563), done. Submodule path 'common': checked out '9aed1d7a80a38b76f9441ecf181942df99f09c38' Cloning into 'gst-libs/ext/libav'... remote: Counting objects: 442640, done. remote: Compressing objects: 100% (95812/95812), done. remote: Total 442640 (delta 351980), reused 436519 (delta 346093) Receiving objects: 100% (442640/442640), 104.61 MiB | 1.47 MiB/s, done. Resolving deltas: 100% (351980/351980), done. Submodule path 'gst-libs/ext/libav': checked out '15466db69e60f486c44e4c3e680d27c951f125d7' + passing argument --prefix=/home/v to configure + passing argument --disable-gtk-doc to configure + options passed to configure: --prefix=/home/v --disable-gtk-doc + check for build tools checking for autoreconf ... /home/v/bin/autoreconf checking for pkg-config ... /usr/bin/pkg-config configure.ac:68: installing './compile' configure.ac:10: installing './config.guess' configure.ac:10: installing './config.sub' configure.ac:13: installing './install-sh' configure.ac:13: installing './missing' Makefile.am: installing './INSTALL' ext/libav/Makefile.am:1: error: Libtool library used but 'LIBTOOL' is undefined ext/libav/Makefile.am:1: The usual way to define 'LIBTOOL' is to add 'LT_INIT' ext/libav/Makefile.am:1: to 'configure.ac' and run 'aclocal' and 'autoconf' again. ext/libav/Makefile.am:1: If 'LT_INIT' is in 'configure.ac', make sure ext/libav/Makefile.am:1: its definition is in aclocal's search path. ext/libav/Makefile.am: installing './depcomp' ext/libswscale/Makefile.am:1: error: Libtool library used but 'LIBTOOL' is undefined ext/libswscale/Makefile.am:1: The usual way to define 'LIBTOOL' is to add 'LT_INIT' ext/libswscale/Makefile.am:1: to 'configure.ac' and run 'aclocal' and 'autoconf' again. ext/libswscale/Makefile.am:1: If 'LT_INIT' is in 'configure.ac', make sure ext/libswscale/Makefile.am:1: its definition is in aclocal's search path. parallel-tests: installing './test-driver' autoreconf: automake failed with exit status: 1
What's the output of: $ which autoconf automake libtool ? I suspect you're on an older distro and installed one of autoconf/automake/libtool in a different prefix, so that some .m4 files ended up in a prefix where they're not being found by one of the other tools.
(In reply to Tim-Philipp Müller from comment #8) > What's the output of: > > $ which autoconf automake libtool > > ? > > I suspect you're on an older distro and installed one of > autoconf/automake/libtool in a different prefix, so that some .m4 files > ended up in a prefix where they're not being found by one of the other tools. This is correct. /home/v/bin/autoconf /home/v/bin/automake /usr/bin/libtool I have ACLOCAL_PATH pointing to /home/v/share/aclocal though, but maybe there's one I'm missing. I will look into this some more with that in mind.
A bit of looking around found this, which worked for me from a fresh gst-libav: http://stackoverflow.com/questions/18978252/error-libtool-library-used-but-libtool-is-undefined Rerunning these three commands "fixes" my issue: libtoolize aclocal autoheader Maybe this could go in the autogen.sh ? Weirdly, all other plugin repos (-base, etc) build just fine, it's just gst-libav that fails here. I see no relevant differences between -base and -libav (there's just an extra call to AG_GST_LIBTOOL_PREPARE, but removing it did not change behavior).
autogen.sh should be calling those three (+ automake) already. Not for you?
I don't see calls to libtoolize (at least from git grep in gst-libav and gst-libav/common). Where is it supposed to be called ?
Looks like libtoolize should be called from autoreconf, but it's not. Other things like automake are called from it though. With a clean repo, just running libtoolize "fixes" the issue. autoreconf does not run libtoolize because it thinks gst-libav is not using libtool, due to: $uses_libtool = 1 if $macro eq "AC_PROG_LIBTOOL" || $macro eq "LT_INIT"; In -base, LT_INIT is found, but not in -libav (same for AM_GNU_GETTEXT, parenthetically). It looks like the m4 directory is pretty empty in gst-libav, and copying what's in gstreamer/m4 (from core) to gst-libav/m4 fixes this (ie, autoreconf now thinks we're using libtool, and runs libtoolize, fixing my original problem). Those m4 files aren't installed by core AFAICT (they're not in $HOME/share/aclocal, and make install in core/m4 does not try to install them anywhere). Should they (or the libtool relevant ones) be either installed by core, or shipped in the gst-libav/m4 tree ? Or should it be irrelevant to autoreconf's (in fact, autom4te's, if I read autoreconf right) determination of whether libtool is used ?
common/m4 should contain LT_INIT and that should be added to the M4 include path and stuff. And the m4 files for libtool in core are AFAIK just copied in there by autoreconf.
I thought only gst-libav had that problem, so I was comparing with gst-plugins-base to find differences, but -base started seeing this too from a fresh clone. In the end, it turned out to be a too old libtool. 2.4.2 is too old, using 2.4.6 fixes it. Not sure if it's worth adding a libtool version check, similar how there is an automake one. If not, I guess this can be closed as invalid.
Well, add one to gst-autogen.sh in common :) And next time common is synced, it will fail properly then.
No, not in *autogen.sh*, I've removed all the version checks there. Adding LT_PREREQ([2.4.6]) to configure.ac should do the trick.
Created attachment 313115 [details] [review] libtool version check I tried versions between those, and settled on 2.4.4. If ok'd, I'll push the same to core and other plugins too.
Comment on attachment 313115 [details] [review] libtool version check common/m4/as-libtool.m4: LT_PREREQ([2.2.6]) Let's just add it there? Or doesn't that work?
Created attachment 313116 [details] [review] libtool version check It does work, thank you :)
Hmm, common master has done away with the libtool version check, actually. Are you fine with me adding it again, Tim ? I end up with this when applying to common master: @@ -41,5 +41,6 @@ AC_DEFUN([AS_LIBTOOL], fi AC_SUBST([$1]_LT_LDFLAGS) + LT_PREREQ([2.4.4]) AC_LIBTOOL_DLOPEN ])
Sure, that's fine and is good to have IMO. What I would like to avoid is checks in autogen.sh that do libtool --version and then try to parse that number and make sense of it. It should be enough to have the requirement somewhere in configure.ac and/or .m4 files and then autoreconf/autotools should check it based on that.
Actually, the version check was here, the tree got moved to another ref. Phew, that took me a good while, just for this. commit d689b7e777103ca4f542cbfd9c6cc810679f72d1 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Mon Oct 12 13:18:20 2015 +0100 as-libtool.m4: bump libtool requirement to 2.4.4 Earlier versions now fail with the switch to autoreconf. https://bugzilla.gnome.org/show_bug.cgi?id=754690
This means that people like me running Ubuntu LTS won't be able to build anymore (libtool 2.4.2). I am not sure I understand what issue the change is fixing, sicne so far I could build all modules just fine.
Does it build from a fresh clone ? I had 2.4.2 too, and the breakage only became apparent when I tried to build a fresh clone (or a tree after running git clean -fdx).
I did a fresh checkout: git clone --recursive ssh://git.freedesktop.org/git/gstreamer/gstreamer cd gstreamer ./autogen.sh and it configures fine. It also builds. But ./libtool --version reports 2.4.2, so what does the version check actually do? Also I think you need to do a git submodule update. Otherwise this won't take effect. If I manually bump that i my checkout, it fails as expected: configure.ac:65: error: Libtool version 2.4.4 or higher is required m4/libtool.m4:48: LT_PREREQ is expanded from... common/m4/as-libtool.m4:26: AS_LIBTOOL is expanded from... configure.ac:65: the top level autom4te: /usr/bin/m4 failed with exit status: 63
Yes, we haven't synced the modules to after that common change yet. It's a bit unfortunate to require 2.4.6 if LTS only has 2.4.2, but what's the alternative? Just drop the check for the time being because it mostly works with older ones too?
That's very curious. I could go back and debug some more to find what libtool change exactly "fixes" it for me, but that might take a while. I have Ubuntu 12.04.5 here. Or we could drop the check as tpm says.
If I install libtool 2.4.2 in my $HOME, it [1] all works. It just doesn't work with the libtool that comes from the OS (which presents itself as 2.4.2 too). Replacing files bit by bit (I know, that may introduce unrelated issues), it starts to work after replacing libtool.m4. I managed to delete my /usr copy of it though (don't keep the temp backup where you will git clean -fdx). There are few differences, and most are just for netbsd. At this point, I'm tempted to just say my particular OS version had a libtool just before what's needed, and revert the change if it causes more trouble.
Vincent, thanks for testing. Just for the record, what OS are you using? If I understood correctly 2.4.2 works for you as well. Can we then revert the change in common, or change the required version to be 2.4.2.
I use Ubuntu 12.04.5. 2.4.2 from that OS does not work. 2.4.2 from the FSF does. Both those versions are pretty similar, with the change that "breaks" it for me being in libtool.m4.
I reverted the patch now. Sorry for the noise.