After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 754690 - libtool versions earlier than 2.4.4 fail with autoreconf
libtool versions earlier than 2.4.4 fail with autoreconf
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other Linux
: Normal normal
: 1.7.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-09-07 15:25 UTC by Vincent Penquerc'h
Modified: 2015-10-20 13:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
add LT_INIT (690 bytes, patch)
2015-09-07 15:27 UTC, Vincent Penquerc'h
none Details | Review
remove obsolete configuration flags (1.48 KB, patch)
2015-09-07 15:28 UTC, Vincent Penquerc'h
none Details | Review
libtool version check (724 bytes, patch)
2015-10-12 12:07 UTC, Vincent Penquerc'h
none Details | Review
libtool version check (735 bytes, patch)
2015-10-12 12:19 UTC, Vincent Penquerc'h
committed Details | Review

Description Vincent Penquerc'h 2015-09-07 15:25:22 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.
Comment 1 Vincent Penquerc'h 2015-09-07 15:27:06 UTC
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
Comment 2 Vincent Penquerc'h 2015-09-07 15:28:08 UTC
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).
Comment 3 Vincent Penquerc'h 2015-09-07 15:28:51 UTC
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 4 Sebastian Dröge (slomo) 2015-09-07 15:31:13 UTC
Comment on attachment 310834 [details] [review]
add LT_INIT

It's called by AS_LIBTOOL already, libtool just doesn't see that.
Comment 5 Sebastian Dröge (slomo) 2015-09-07 15:34:03 UTC
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.
Comment 6 Sebastian Dröge (slomo) 2015-09-07 15:34:59 UTC
automake (GNU automake) 1.15
autoconf (GNU Autoconf) 2.69
libtool (GNU libtool) 2.4.2

here
Comment 7 Vincent Penquerc'h 2015-09-07 15:48:04 UTC
(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
Comment 8 Tim-Philipp Müller 2015-09-11 23:28:15 UTC
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.
Comment 9 Vincent Penquerc'h 2015-09-12 12:05:00 UTC
(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.
Comment 10 Vincent Penquerc'h 2015-10-08 11:13:54 UTC
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).
Comment 11 Sebastian Dröge (slomo) 2015-10-08 13:56:35 UTC
autogen.sh should be calling those three (+ automake) already. Not for you?
Comment 12 Vincent Penquerc'h 2015-10-08 14:52:12 UTC
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 ?
Comment 13 Vincent Penquerc'h 2015-10-09 10:18:53 UTC
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 ?
Comment 14 Sebastian Dröge (slomo) 2015-10-10 08:48:25 UTC
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.
Comment 15 Vincent Penquerc'h 2015-10-12 11:12:08 UTC
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.
Comment 16 Sebastian Dröge (slomo) 2015-10-12 11:21:58 UTC
Well, add one to gst-autogen.sh in common :) And next time common is synced, it will fail properly then.
Comment 17 Tim-Philipp Müller 2015-10-12 11:33:31 UTC
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.
Comment 18 Vincent Penquerc'h 2015-10-12 12:07:06 UTC
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 19 Sebastian Dröge (slomo) 2015-10-12 12:12:16 UTC
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?
Comment 20 Vincent Penquerc'h 2015-10-12 12:19:46 UTC
Created attachment 313116 [details] [review]
libtool version check

It does work, thank you :)
Comment 21 Vincent Penquerc'h 2015-10-12 13:55:09 UTC
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
 ])
Comment 22 Tim-Philipp Müller 2015-10-12 14:03:06 UTC
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.
Comment 23 Vincent Penquerc'h 2015-10-12 14:17:19 UTC
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
Comment 24 Stefan Sauer (gstreamer, gtkdoc dev) 2015-10-18 18:05:50 UTC
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.
Comment 25 Vincent Penquerc'h 2015-10-18 18:14:39 UTC
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).
Comment 26 Stefan Sauer (gstreamer, gtkdoc dev) 2015-10-19 13:51:31 UTC
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
Comment 27 Tim-Philipp Müller 2015-10-19 14:02:19 UTC
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?
Comment 28 Vincent Penquerc'h 2015-10-19 14:08:34 UTC
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.
Comment 29 Vincent Penquerc'h 2015-10-20 11:28:06 UTC
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.
Comment 30 Stefan Sauer (gstreamer, gtkdoc dev) 2015-10-20 13:40:04 UTC
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.
Comment 31 Vincent Penquerc'h 2015-10-20 13:48:22 UTC
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.
Comment 32 Vincent Penquerc'h 2015-10-20 13:50:47 UTC
I reverted the patch now. Sorry for the noise.