search

blueprintmrk / snappy

Automatically exported from code.google.com/p/snappy
Other
0 stars 0 forks source link

autoreconf fails due to missing AC_PROG_LIBTOOL #43

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

  1. checkout the trunk
  2. 'autoreconf' fails with: Libtool library used but `LIBTOOL' is undefined

What version of the product are you using? On what operating system?

  CentOS 5.5 64
  Autoconf 2.68

Adding 'AC_PROG_LIBTOOL' at the end of configure.ac fixes the problem.

Original issue reported on code.google.com by tuc...@gmail.com on 16 May 2011 at 10:19

GoogleCodeExporter commented 9 years ago 
AC_PROG_LIBTOOL is an outdated name for LT_INIT, which is in configure.ac. What 
version of libtool do you have installed?

Original comment by se...@google.com on 16 May 2011 at 10:21

GoogleCodeExporter commented 9 years ago 
Also, have you tried using autogen.sh, which is the recommended way of doing 
this, instead of autoreconf?

Original comment by se...@google.com on 18 May 2011 at 8:03

GoogleCodeExporter commented 9 years ago 
I've been using the 'autogen.sh' script.

The versions of tools I have are:

automake 1.9.6
libtool 1.5.22
autoconf 2.68

It has been trial an error getting the versions of them as there is no 
documentation on what are are required versions. 

Thanks.

Original comment by tuc...@gmail.com on 18 May 2011 at 1:32

GoogleCodeExporter commented 9 years ago 
Do you have the full output of ./autogen.sh from a clean checkout?

Original comment by se...@google.com on 19 May 2011 at 10:08

GoogleCodeExporter commented 9 years ago 
Here it goes:

-------
$ ./autogen.sh 
Remember to add `AC_PROG_LIBTOOL' to `configure.ac'.
You should update your `aclocal.m4' by running aclocal.
configure.ac: installing `./install-sh'
configure.ac: installing `./missing'
Makefile.am: installing `./INSTALL'
Makefile.am:4: Libtool library used but `LIBTOOL' is undefined
Makefile.am:4: 
Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
Makefile.am:4: to `configure.ac' and run `aclocal' and `autoconf' again.
Makefile.am: installing `./depcomp'
$
-------

Thanks.

Original comment by tuc...@gmail.com on 19 May 2011 at 10:21

GoogleCodeExporter commented 9 years ago 
Try with libtool 2.4 and see if it makes a difference. 1.5.x is pretty old at 
this stage.

Original comment by se...@google.com on 20 May 2011 at 6:45

GoogleCodeExporter commented 9 years ago 
I've installed libtool 2.4, still same error (see below).

It gets fixed if I add AC_PROG_LIBTOOL to the configure.ac

With libtool 2.4 I don't have to invoke make with the 'LIBTOOL=libtool' option.

It would be great if the README states the required versions of tools (autconf, 
libtool, etc).

Thanks.

Alejandro

--------
$ autoconf --version
autoconf (GNU Autoconf) 2.68

$ libtool --version
libtool (GNU libtool) 2.4

$ ./autogen.sh 
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac: installing `./install-sh'
configure.ac: installing `./missing'
Makefile.am: installing `./INSTALL'
Makefile.am:4: Libtool library used but `LIBTOOL' is undefined
Makefile.am:4: 
Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
Makefile.am:4: to `configure.ac' and run `aclocal' and `autoconf' again.
Makefile.am: installing `./depcomp'
--------

Original comment by tuc...@gmail.com on 23 May 2011 at 5:54

GoogleCodeExporter commented 9 years ago 
To be honest, this sounds like autoconf is somehow picking up old libtool m4 
files, although I don't think I understand the specifics. Here's how it looks 
on my machine:

fugl:~/snappy> automake --version 
automake (GNU automake) 1.11.1
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later 
<http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey <tromey@redhat.com>
       and Alexandre Duret-Lutz <adl@gnu.org>.
fugl:~/snappy> autoconf --version
autoconf (GNU Autoconf) 2.68
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.
fugl:~/snappy> libtool --version
libtool (GNU libtool) 2.4
Written by Gordon Matzigkeit <gord@gnu.ai.mit.edu>, 1996

Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

fugl:~/snappy> ./autogen.sh 
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:16: installing `./config.guess'
configure.ac:16: installing `./config.sub'
configure.ac:14: installing `./install-sh'
configure.ac:14: installing `./missing'
Makefile.am: installing `./INSTALL'
Makefile.am: installing `./depcomp'

Again, I can't just add AC_PROG_LIBTOOL, since you can't init libtool twice 
(LT_INIT is already called, which is the proper name for AC_PROG_LIBTOOL these 
days).

I also tried downgrading automake to 1.9, but it still works fine for me.

What is this LIBTOOL=libtool that you mentioned? You haven't written anything 
about it earlier in the bug report.

Original comment by se...@google.com on 23 May 2011 at 10:23

GoogleCodeExporter commented 9 years ago 
Still no luck, with automake 1.11.1 now autogen.sh fails with other error ( see 
below)

With automake 1.9.6, if adding the AC_PROG_LIBTOOL macro I could autogen, then 
I had to invoke make with 'LIBTOOL=libtool', otherwise it would fail as libtool 
was no being resolved.

Thanks for your patience.

--------------
$ autoconf --version
autoconf (GNU Autoconf) 2.68

$ libtool --version
libtool (GNU libtool) 2.4

$ automake --version
automake (GNU automake) 1.11.1

$ ./autogen.sh 
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:16: installing `./config.guess'
configure.ac:16: installing `./config.sub'
configure.ac:14: installing `./install-sh'
configure.ac:14: installing `./missing'
Makefile.am: installing `./INSTALL'
Makefile.am: installing `./depcomp'
configure.ac:40: error: possibly undefined macro: AC_DEFINE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:42: error: possibly undefined macro: AC_MSG_FAILURE

Original comment by tuc...@gmail.com on 23 May 2011 at 11:08

GoogleCodeExporter commented 9 years ago 
Mm, OK. It's a bit weird that AC_DEFINE is “undefined macro”; it indicates 
something is very wrong with your autotools setup. Would it be possible to 
borrow a temporary account somewhere where this happens? (My guess is that 
there's a different autoconf somewhere whose m4 files are pulled in.)

Original comment by se...@google.com on 27 May 2011 at 9:58

GoogleCodeExporter commented 9 years ago 
Hi,

I borrowed access to a CentOS system, and reproduced your error.

The fix is simple: Remove the old libtool version (yum remove libtool). CentOS' 
versions seemingly conflicts with what upstream puts in (or you simply can't 
have autotools stuff in both /usr and /usr/local reliably; I don't know).

Closing since this is not a Snappy bug.

Original comment by se...@google.com on 30 May 2011 at 8:46

GoogleCodeExporter commented 9 years ago

Original comment by se...@google.com on 30 May 2011 at 8:48

GoogleCodeExporter commented 9 years ago 
thanks for sorting this out

Original comment by tuc...@gmail.com on 30 May 2011 at 11:42

GoogleCodeExporter commented 9 years ago 
My sollution was delete the snappy untgzed path, extract again, and there I was.

Fact: I was using a extracted already used to compile to different CentOS, even 
after "make clean".

Original comment by jfhto...@gmail.com on 23 Dec 2011 at 12:18