Possibly undefined macro: AC_PROG_LIBTOOL

Question

I want to build protobuf, so I just cloned the package and cd in the directory. When I type ./autogen.sh, some error happened.

I receive callback:

configure.ac:104: error: possibly undefined macro: AC_PROG_LIBTOOL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /home/zhangxl/my/autoconf/bin/autoconf failed with exit status: 1

Someone said I should install libtool, but I have already installed autoconf, automaker, libtool and m4, but all of them are built from source, because I can't access the sudo password.

This is my .bashrc file:

export PATH=$PATH:/home/zhangxl/my/libtool/bin
export CPLUS_INCLUDE_PATH=/hpme/zhangxl/my/libtool/include:$CPLUS_INCLUDE_PATH
export LIBRARY_PATH=/home/zhangxl/my/libtool/lib:$LIBRARY_PATH
export LD_LIBRARY_PATH=/home/zhangxl/my/libtool/lib:$LD_LIBRARY_PATH

I think maybe the .bashrc file is not correct.

Burnt

Autotools is mostly (completely?) broken when it comes to updating them. You basically have to use what the distro provides. (I've never been able to update them on Linux, Solaris or OS X; and the Compile Farm admins have never been able to do it on AIX or Linux. Attempts to use the updated tools results in a cornucopia of failures). – Salutation

You will likely have better success by downloading the package of interest to a machine you are admin on, update it and repackage for the destination machine, and then scp'ing the updated package to the destination machine. Effectively, you are building the package offline just like the maintainers. – Salutation

FWIW, @jww, I have several times successfully updated the Autotools on the Linux machines I manage, yielding resulting installs that work fine. The only thing that made it tricky, as far as I could tell, was the packaging (I built and installed replacement RPMs), not the Autotools themselves. Of course, "work fine" encompasses the normal issues with specific packages sometimes having trouble with different Autotools versions than their maintainers use. – Albany

A few years ago when I had to build software on OS X, rebuilding the entire GNU Build System (for our code at least) was basically mandatory -- the OS X provided ones were usually laughably out of date. IIRC for Solaris I used the SunFreeware GNU Build System packages instead of the provided ones. – Jiles

To anyone viewing this question in the future, I found that this question had better help explaining how to fix this issue on superuser.com/q/565988/876751. In my case I had installed autoconf, but not libtool so I needed to run sudo apt-get install libtool to fix the issue. – Schwa

Answer 1

Make sure you have libtool installed. This error message can be produced by autoconf if it can not find libtool on your system. In my case, the error looked a bit like this:

autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf
...
configure.ac:41: error: possibly undefined macro: AC_PROG_LIBTOOL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

I was able to fix the issue by installing libtool with apt.

sudo apt-get update
sudo apt-get install libtool

Schwa

I'm having a problem even though libtool and libtoolize is on the $PATH. Is there som environment variable I can use to tell autoconf about my libtool? – Vasoconstrictor

Answer 2

libtool is more than just a (set of) binaries. it also includes a couple of m4-macros (to be used by autotools), among them the AC_PROG_LIBTOOL macro.

Since you didn't do a "proper" installation of libtool, autoconf is not finding these additional macros.

Look out for files like libtool.m4, ltoptions.m4 ... (probably somewhere in /home/zhangxl/my/libtool/share/aclocal/ and add the path to the autoreconf invocation. Something like:

autoreconf  -f -i -Wall,no-obsolete -I/home/zhangxl/my/libtool/share/aclocal/

(in case you wondered: autoreconf is being called by autogen.sh, near the end of that script; so when you've called autogen.sh, most things already succeeded, only the invocation of autoreconf failed, and that's what the above line fixes. if you want to be able to call autogen.sh again, you must change the line with autoreconf as seen above)

Nipha

Answer 3

When I type ./autogen.sh,some error happened.

It is a design goal of the Autotools that they are not part of ordinary builds. The Autotools are used for building the build system, which is a package maintainer responsibility. People who merely want to build the project should not (according to Autotools philosophy) invoke the Autotools at all -- instead, they should use the build system that has already been provided to them, consisting of a configure script, Makefile and header templates, etc..

Thus, the first thing to try should always be to unpack a clean copy the distribution, and, without running autogen.sh, autoreconf, or similar, perform a standard configure; make; make install sequence. In that case, the Autotools should not need even to be installed on the build host. Only if the existing build system needs to be modified for your environment, or if none is provided in the first place, should you look into (re)building the build system.

If you do need to rebuild the build system -- which is not as uncommon as GNU would like -- then the smoothest way forward is to use the same versions of the Autotools that the package maintainers use. More recent versions are often a viable substitute, to a point, but sometimes they require adjustments to the Autotools inputs. Older versions can be problematic. You must remain well aware, however, that this puts you in the role of a package maintainer, not a mere package builder. Rebuilding the build system opens you to a need to solve problems specific to that endeavor.

Sometimes, version compatibility issues can be partially or wholly resolved by instructing the Autotools to replace the scripts and local m4 macros that they install into the project source tree. If the project provides an autogen.sh, it might or might not do this. The command autoreconf --install --force, run from the root of the source tree, will take care of all those Autotools pieces, but might not do other things that autogen.sh does. It is probably worth your while to check out what your particular autogen.sh does, and it might be useful to run both autoreconf and autogen.sh, probably in that order.

I think maybe the .bashrc file is not right

It is unlikely that the particular error message you presented reflects a problem with your environment configuration. It could reflect an issue with your DIY local Autotools -- more likely Libtool than the others -- but there is a fair chance that it reflects an incompatibility between the Autotools versions used by the package's maintainers and the ones you have built.

Albany

Answer 4

I have faced similar issue and to resolve i have removed yum installed package and installed with dnf as shown below

$yum remove automake
$dnf install automake

Terreverte

Answer 5

It seems that you should install automake/autoconf/libtool to the same direction.
I got the same problem and solved it this way.
Solution comes from https://users.open-mpi.narkive.com/6uyEU5GH/ompi-possibly-undefined-macro-ac-prog-libtool

Geoffrey

Answer 6

Based on other answers, you could try adding this line

export ACLOCAL_PATH=/home/zhangxl/my/libtool/share/aclocal:$ACLOCAL_PATH

and system can find the macros autoreconf need.

Costplus

This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review – Helprin

Answer 7

I haven't read all the answers but the line :

export CPLUS_INCLUDE_PATH=/hpme/zhangxl/my/libtool/include:$CPLUS_INCLUDE_PATH

contains a typing error

Botti

This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review – Manchukuo