possibly undefined macro: AC_MSG_ERROR

Question

I have the following in configure.ac:

AC_CHECK_PROGS(MAKE,$MAKE make gmake,error)
if test "x$MAKE" = "xerror" ;then
  AC_MSG_ERROR([cannot find a make command])
fi

This has been in our project for a long time, but in some set ups, I get this error:

configure.ac:45: error: possibly undefined macro: AC_MSG_ERROR
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.

The lines that were recently added above this:

AC_CONFIG_MACRO_DIR([m4])
LT_INIT

Can anyone explain what causes this error and how to track down the problem?

EDIT: Adding details about the differences.

Box that works:

uname -a Linux host1 2.6.38-13-generic #53-Ubuntu SMP Mon Nov 28 19:33:45 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

automake: 1.11.1
autoconf: 2.67
m4: 1.4.14
libtoolize: 2.2.6b

Box that doesn't work:

Linux host2 2.6.32-35-generic-pae #78-Ubuntu SMP Tue Oct 11 17:01:12 UTC 2011 i686 GNU/Linux

automake: 1.11.1
autoconf: 2.65
m4: 1.4.13
libtoolize: 2.2.6b

NEW EDIT: only 32 bit machines experience this difficulty.

UPDATED I am able to reproduce the problem on a CentOS machine with autoconf 2.67, automake 1.11.1, libtool 2.2.6b, and m4 1.4.14. Is this just a bug with 32-bit machines?

Blat

Why is this a problem? Build your tarballs with autoconf 2.67. You only need to have autoconf installed on one machine! – Exuviae

I am aware I can work around the issue easily, I'm just trying to make sure its an issue with the one box and not a problem in our configure.ac or other config files. – Blat

I know that autoconf 2.64 was considered fairly buggy. Possibly you are experiencing a bug in 2.65. – Exuviae

I am able to reproduce the problem on another 32-bit machine with autoconf 2.67, automake 1.11.1, libtool 2.2.6b, and m4 1.4.14 – Blat

I cannot imagine this helping: but have you tried AC_CHECK_PROGS([MAKE],[$MAKE make gmake],[error]) ? It definitely sounds like an m4 issue, and fully quoting things to m4 can only help. This particular line is probably not the culprit, but it smells like a quoting issue somewhere. Can you post the full configure.ac? – Exuviae

The entire file is over 2000 lines long, but it is part of the TORQUE open source project. You can check out the source svn co svn://svn.clusterresources.com/torque/trunk – Blat

Answer 1

I had this same issue and found that pkg-config package was missing.

After installing the package, everything generated correctly.

Kimberly

I had the same issue as well, specifically this error message: "If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation." and it was also a case of missing pkg-config. – Fredrick

Thanks! Outlining my case, for the next guy in the same shoes. For the sake of having reproducible builds I have to use a toolchain of custom paths to all GNU Build System tools. The equivalent of installing pkg-config was not only to modify PATH but also to add "-I /toolchain_local/pkg-config-0.23/share/aclocal" to the autoreconf commandline. Took me some time to realize that pkg-config does not install only binaries. rpm -ql pkgconfig helped. – Chaddy

Awesome thanks. Just had this when trying to build glusterfs on a brand new FreeBSD build (which now uses pkgconf, and works with it). – Quitrent

I had to install libtool. – Demonstrator

Just FYI technically this isn't fixing the problem. In this case the AC_MSG_ERROR was trying to say "you need to install pkg-config" but for some reason it was unable to print this message (giving the error about AC_MSG_ERROR). By installing pkg-config there was no longer any need to print an error message, so the AC_MSG_ERROR line was skipped and things work. Fine if you are installing someone else's package, but if it's your own code, you still haven't fixed the problem :-) – Bouzoun

I've encountered this issue before, and installing the autoconf-archive package fixed the issue. – Stellite

Wow, this is an example of autoreconfig spitting out a really bad error message. – Scraperboard

Fixed the broken built of rocket-chip on debian testing for me. Thnx! – Workhorse

Answer 2

It is recommended to use autoreconf -fi instead of manually calling aclocal;autoconf;automake; #and whatever else to properly populate aclocal.m4 and so on.

Adding ACLOCAL_AMFLAGS = -I m4 (to the toplevel Makefile.am) and AC_CONFIG_MACRO_DIR([m4]) is currently still optional if you do not use any own m4 files, but of course, doing it will silence the proocess :)

Halla

We have m4 files, so that is required for us. Also, changing things to autoreconf -fi produces the same error. – Blat

If you do have m4 files, ACLOCAL_AMFLAGS and AC_CONFIG_MACRO_DIR is exactly what you should do. (And putting the files in m4/, resp. the dir that you specified) – Tripp

I had this exact same problem and found that I'd missed out setting ACLOCAL_AMFLAGS in Makefile.am - thanks! – Foreland

Autotools are so broken... None of this crap makes sense. How can it be in 30 years things are still this broken? – Filling

Answer 3

I had this problem with my own configure.ac, but in this case (and for the benefit of anyone here from Google) it was because I had accidentally quoted the AC_MSG_ERROR so it was being treated as a string:

AX_BOOST_BASE([1.42], [], [AC_MSG_ERROR([Could not find Boost])])

Once I removed the square brackets around the AC_MSG_ERROR macro, it worked:

AX_BOOST_BASE([1.42], [], AC_MSG_ERROR([Could not find Boost]))

Those comments saying you should install pkg-config or some package are missing the point. The AC_MSG_ERROR is supposed to work and give you a helpful message like "You need to install package XYZ", but because of some problem, the AC_MSG_ERROR doesn't work. Installing package XYZ will certainly make the error go away, but only because once the package is there, there is no longer any need to print an error message!

So installing pkg-config or a particular package just bypasses the problem, it doesn't actually fix it.

Bouzoun

It makes error gone. But will throw error on ./configure script – Gromme

Answer 4

I had the same problem on RHEL7.5 with otto-de/libvmod-uuid

It was fixed by installing "autoconf-archive" packages

Girondist

I needed "autoconf-archive" Debian package to build powertop v2,31-rc1. – Ashok

I needed this to build tpm2-tools – Revolving

needed for python on macos – Fireworm

Answer 5

i also had similar problem.. my solution is to

apt-get install libcurl4-openssl-dev

(i had libcurl allready installed ) worked for me at least..

Bara

Answer 6

I have experienced this same problem under CentOS 7

In may case, the problem went off after installation of libcurl-devel (libcurl was already installed on this machine)

Commandeer

Answer 7

There are two possible reasons for that problem:

1. did not install aclocal.
   solution：install libtool

   • For ubuntu: sudo apt-get install libtool
   • For centos: sudo yum install libtool

2. the path to LIBTOOL.m4 is error.
   solution:

   1. use aclocal --print-ac-dir to check current path to aclocal.(It's usually should be "/usr/share/aclocal" or "/usr/share/aclocal")
   2. Then check if there are *.m4 files.
   3. If not, cp corresponding *.m4 files to this path.( Maybe cp /usr/share/aclocal/*.m4 /usr/local/share/aclocal/ or cp /usr/local/share/aclocal/*.m4 /usr/share/aclocal/)

Hope it helps

Autotruck

Answer 8

I just lost a few hours on this one. My conclusion:

• Depending on version and whatever other local conditions, autoconf will spit out the message about AC_MSG_ERROR undefined when it encounters ANY undefined macro. The AC_MSG_ERROR is a red herring. The causes for an undefined macro can be:
  • A typo in a macro name in the file, or a local macro which has not been shipped with the tarball
  • Missing a package which would have come with a set of autoconf macros, one of which is used in the file. pkg-config is often the missing one (because of, e.g.,PKG_CHECK_MODULES), but this could be any other package supplying a needed but absent macro. The vicious thing of course, is that this happens before the still not existing configure script could check for the missing package...

Macready

This is the answer! Ultimately this is a bad error message from autoconf. – Emunctory

Answer 9

Are you setting up a local 'm4' directory? e.g.,

> aclocal -I m4 --install

Some packages come with an autogen.sh or initgen.sh shell script to run glibtoolize, autoheader, autoconf, automake. Here's an autogen.sh script I use:

#! /bin/sh

case `uname` in Darwin*) glibtoolize --copy ;;
  *) libtoolize --copy ;; esac

autoheader
aclocal -I m4 --install
autoconf

automake --foreign --add-missing --force-missing --copy

EDIT

You may need to add ACLOCAL_AMFLAGS = -I m4 to the top-level Makefile.am.

Aquavit

Does autoreconf not select the proper libtoolize on Darwin? – Exuviae

I am setting up a local 'm4' directory. I added -I m4 --install to aclocal, but I get the same error. This is my autogen.sh script: libtoolize -c -f autoheader -f aclocal -I m4 --install autoconf -f automake --foreign --add-missing --force-missing --copy – Blat

@dbeer, added the ACLOCAL_AMFLAGS variable? – Aquavit

@WilliamPursell no, it doesn't. MacOS features the GNU libtool as 'glibtool', and the one provided by Apple (which doesn't behave like expected by a GNU libtool) as 'libtool'. Note that also libtoolize is installed as 'glibtoolize'. This can be overriden by specifying LIBTOOLIZE and LIBTOOL macro. Despite this autogen sample is good, it's often better to simply run autoreconf -fi and let it guess/recover the -I flag from the previous run, especially when the software isn't yours. – Rossi

@WilliamPursell - old Q/A, but macports certainly does. These days, I don't rely on anything but autoreconf -fvi. If that doesn't work, it's my fault. – Aquavit

Answer 10

On Mac OS X el captain with brew, try:
brew install pkgconfig

This worked for me.

Surrogate

This needs more upvotes, adding comment for visibility – Vitriolic

Answer 11

For Debian. Required packages are: m4 automake pkg-config libtool

Athirst

Answer 12

The error is generated by autom4te. If things are set up correctly, the portion of the code that generates that error should never see 'AC_MSG_ERROR', because it should have been expanded by m4 before that point. You say the error only happens "in some setups". I would suggest that in those setups, your autoconf installation is fubar. Possibly you have an incompatible version of m4 installed.

Exuviae

I am on autoconf 2.65 and m4 1.4.13. Are these compatible? – Blat

m4 1.4.13 is new enough and is not likely the problem. Can you determine what is different about the setups in which you see the warning from those in which you do not? – Exuviae

I just added some of the information on that to my question - can you think of anything else relevant? I'm not very knowledgeable when it comes to autotools. – Blat

Just noticed - 32 bit machines seem to be the ones with difficulty. – Blat

Answer 13

Using MacOS X

sudo port install pkgconfig

was the solution!

Cartouche

this answer is outdated, use brew instead of port – Selflove

Answer 14

I had the same problem on Ubuntu (error: possibly undefined macro: AC_MSG_ERROR) but the answers above didn't work for me. I found the solution here

That did the trick:

$ LANG=C LC_CTYPE=C ./autogen.sh

Eskimo

Answer 15

I had similar issues when trying to build amtk and utthpmock with jhbuild.

I needed to install the most recent version of autoconf-archive. Instructions are at https://github.com/autoconf-archive/autoconf-archive/blob/master/README-maint. I did an additional sudo make install at the end.

The last step was to update my ACLOCAL_PATH:

echo 'export ACLOCAL_PATH=$ACLOCAL_PATH:/usr/local/share/aclocal' >> ~/.bashrc

After a source ~/.bashrc, all the macros were finally found and the builds succeeded.

Laterality

This is the solution if someone met this problem on macos. – Chiffchaff

Answer 16

My issue is resolved after I install pkg-config on Mac (brew install pkg-config)

Mimesis

Answer 17

I solved this by yum install libtool

Lawtun

after I finish compile pkg-config – Lawtun

Answer 18

This happened to me when I forgot a , in the arguments for a locally defined macro. Spent hours trying to figure it out (barely acquainted with autotools)...

AC_CHECK_MACRO([Foo]
    AC_LOCAL_DO([......

should have been

AC_CHECK_MACRO([Foo],      # <-- Notice comma, doh!
    AC_LOCAL_DO([......

Seems like it should have given me an error or such, but I suppose being a macro processor it can only do what its told.

Dolli

Answer 19

you are pulling automake in one version / location and autoconf in another. you either want to remove the offending autoconf or automake from your path and make sure you have the right version

Gambrel

Although Automake works as an adjunct to Autoconf, the two are separate projects. They are not version-locked with each other. There is some version dependency, but the combination of versions that this 10-year-old question claims were in use is a working one. – Gravettian

As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. – Penates

Answer 20

I also had this problem bootstrapping (autoreconf) PC/SC lite on Debian bullseye (with up-to-date autotools installed). The reason was simple: the two M4 macros AX_PTHREAD and AX_RECURSIVE_EVAL were not defined. So I googled the .m4 files, downloaded them, copied them into /usr/share/aclocal and it finally worked. GNU autotools are a common source for problems. If you can just perform: "./configure && make" you are a lucky person. If you have to use autoreconf because you have to modify configure.ac et.al., then many many problems can stop this stuff from working:

• wrong/outdated versions of autotools installed
• very old configure.ac and/or Makefile.am files

The debugging steps posted above are correct and helpful, though.

Ceres

Answer 21

On AlmaLinux 9 fixed by installing autoconf2.7x and autoconf-archive.

Adequate

Answer 22

I had the same problem with the Macports port "openocd" (locally modified the Portfile to use the git repository) on a freshly installed machine.

The permanent fix is easy, define a dependency to pkgconfig in the Portfile: depends_lib-append port:pkgconfig

Perversion