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?

Why is this a problem? Build your tarballs with autoconf 2.67. You only need to have autoconf installed on one machine! — William Pursell, Jan 20 '12 at 15:21
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. — dbeer, Jan 20 '12 at 16:20
I know that autoconf 2.64 was considered fairly buggy. Possibly you are experiencing a bug in 2.65. — William Pursell, Jan 20 '12 at 16:30
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 — dbeer, Jan 20 '12 at 17:26
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? — William Pursell, Jan 20 '12 at 17:53
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 — dbeer, Jan 25 '12 at 21:41

score 318 · Accepted Answer · edited Oct 13 '16 at 17:27

318

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

After installing the package, everything generated correctly.

edited Oct 13 '16 at 17:27

Tombart

30,520
16
123
136

answered Jan 26 '12 at 20:00

mutsu

3,204
1
13
2

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. – John Nov 03 '12 at 05:43
2

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. – Assambar Dec 02 '14 at 15:52
Awesome thanks. Just had this when trying to build glusterfs on a brand new FreeBSD build (which now uses pkgconf, and works with it). – ZXcvbnM Feb 15 '15 at 07:01
12

I had to install `libtool`. – Mitar Feb 12 '16 at 00:49
15

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 :-) – Malvineous Jun 23 '16 at 01:24
31

I've encountered this issue before, and installing the ```autoconf-archive``` package fixed the issue. – jonthalpy Mar 13 '17 at 21:51
7

Wow, this is an example of autoreconfig spitting out a really bad error message. – John Greene Apr 14 '17 at 00:13
Fixed the broken built of rocket-chip on debian testing for me. Thnx! – Phil Nov 24 '17 at 15:53

score 34 · Answer 2 · answered Jan 20 '12 at 19:15

34

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 :)

answered Jan 20 '12 at 19:15

jørgensen

10,149
2
20
27

We have m4 files, so that is required for us. Also, changing things to autoreconf -fi produces the same error. – dbeer Jan 25 '12 at 21:40
1

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) – jørgensen Jan 26 '12 at 12:39
Thanks, `autoreconf -fi` made PCRE compile. – uınbɐɥs Feb 09 '13 at 02:13
I had this exact same problem and found that I'd missed out setting `ACLOCAL_AMFLAGS` in `Makefile.am` - thanks! – simpleigh Sep 06 '14 at 14:31
6

Autotools are so broken... None of this crap makes sense. How can it be in 30 years things are still this broken? – jww Jan 04 '18 at 09:34

score 31 · Answer 3 · answered Jun 23 '16 at 01:21

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.

It makes error gone. But will throw error on ./configure script — Muhammad Irvan Hermawan, May 07 '23 at 05:11

score 13 · Answer 4 · answered Jan 12 '17 at 15:44

13

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..

answered Jan 12 '17 at 15:44

BeatingBytes

353
1
4
8

score 12 · Answer 5 · answered Oct 04 '18 at 04:59

12

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

It was fixed by installing "autoconf-archive" packages

answered Oct 04 '18 at 04:59

Sawit Meekwamdee

121
1
2

1

I needed "autoconf-archive" Debian package to build powertop v2,31-rc1. – dileks Jun 04 '20 at 22:18
I needed this to build tpm2-tools – Ed McMan May 02 '23 at 17:45

score 11 · Answer 6 · answered Oct 18 '14 at 11:50

11

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)

answered Oct 18 '14 at 11:50

jap1968

7,747
1
30
37

score 6 · Answer 7 · answered Mar 05 '18 at 04:17

There are two possible reasons for that problem:

did not install aclocal.
solution：install libtool
- For ubuntu: sudo apt-get install libtool
- For centos: sudo yum install libtool
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

score 6 · Answer 8 · answered Feb 06 '20 at 14:34

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...

This is the answer! Ultimately this is a bad error message from autoconf. — marshall.ward, Aug 25 '23 at 22:18

score 4 · Answer 9 · answered Oct 25 '16 at 06:54

4

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

answered Oct 25 '16 at 06:54

ETech

1,613
16
17

Brett Hale · Answer 10 · 2012-01-11T16:44:54.240

3

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.

edited Jan 11 '12 at 16:44

answered Jan 11 '12 at 10:20

Brett Hale

21,653
2
61
90

Does autoreconf not select the proper libtoolize on Darwin? – William Pursell Jan 11 '12 at 15:04
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 – dbeer Jan 11 '12 at 16:35
1

@dbeer, added the `ACLOCAL_AMFLAGS` variable? – Brett Hale Jan 11 '12 at 16:52
@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. – LeoTh3o Jul 02 '13 at 08:59

score 2 · Answer 11 · answered Apr 22 '13 at 10:28

2

Using MacOS X

sudo port install pkgconfig

was the solution!

answered Apr 22 '13 at 10:28

Johann Horvat

1,285
1
14
18

3

this answer is outdated, use brew instead of port – xiamx Nov 10 '13 at 21:42

score 2 · Answer 12 · answered Feb 19 '16 at 00:56

2

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

This worked for me.

answered Feb 19 '16 at 00:56

us_david

4,431
35
29

score 2 · Answer 13 · answered Jan 11 '12 at 16:20

2

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.

answered Jan 11 '12 at 16:20

William Pursell

204,365
48
270
300

I am on autoconf 2.65 and m4 1.4.13. Are these compatible? – dbeer Jan 11 '12 at 17:40
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? – William Pursell Jan 11 '12 at 17:54
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. – dbeer Jan 11 '12 at 18:13
Just noticed - 32 bit machines seem to be the ones with difficulty. – dbeer Jan 16 '12 at 18:44

score 1 · Answer 14 · answered May 26 '16 at 11:09

1

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

answered May 26 '16 at 11:09

mschoenebeck

377
3
12

score 1 · Answer 15 · answered Jul 12 '16 at 14:32

1

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

answered Jul 12 '16 at 14:32

Pavan Challa

81
7

score 1 · Answer 16 · answered Aug 29 '16 at 11:30

1

I solved this by yum install libtool

answered Aug 29 '16 at 11:30

VictorV

637
7
16

after I finish compile pkg-config – VictorV Aug 29 '16 at 11:31

score 1 · Answer 17 · answered Mar 31 '20 at 20:03

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.

score 0 · Answer 18 · answered Jan 22 '15 at 03:19

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.

score 0 · Answer 19 · answered Jan 11 '22 at 17:27

0

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

answered Jan 11 '22 at 17:27

sfdgsbfdg

1

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. – John Bollinger Jan 11 '22 at 20:02
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](/help/how-to-answer). – Community Jan 12 '22 at 04:45

score 0 · Answer 20 · answered Feb 19 '22 at 22:57

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.

score -1 · Answer 21 · answered Dec 28 '14 at 16:14

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

possibly undefined macro: AC_MSG_ERROR

21 Answers21

Linked