3

I'm trying to build libpsl from GutHub sources. Its requires an autoreconf. Autotools is failing with:

# Try to reconfigure. Autotools is so broken...
libtoolize --force && aclocal && autoheader && autoreconf --force --install
...

libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:62: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:68: error: possibly undefined macro: AC_MSG_CHECKING
configure.ac:70: error: possibly undefined macro: AC_MSG_RESULT
configure.ac:87: error: possibly undefined macro: AC_LINK_IFELSE
configure.ac:88: error: possibly undefined macro: AC_LANG_PROGRAM
configure.ac:222: error: possibly undefined macro: AC_SEARCH_LIBS
...

I found Possibly undefined macro: AC_MSG_ERROR and AS_IF and AC_MSG_ERROR: error: possibly undefined macro, but the guesses are not solving my problem. I've spent about the last 4 hours trying the guesses.

I would like to stop guessing and troubleshoot the problem. The issue I am having is, I cannot find information or procedures on troubleshooting Autotools problems. Confer, "troubleshoot" autoconf site:gnu.org.

The best I have come up with is running the commands with -v, but I don't see an attempt to copy general.m4. If I am not mistaken, general.m4 provides AC_MSG_ERROR so I should see it accessed. So my procedures have obvious gaps or defects. And the files are present:

$ find /usr/local -name general.m4
/usr/local/share/autoconf/autoconf/general.m4
/usr/local/share/autoconf/autotest/general.m4

How does one troubleshoot a Possibly undefined macro: AC_MSG_ERROR problem with Autotools?

jww
  • 97,681
  • 90
  • 411
  • 885
  • I find it strange that you are manually calling `libtoolize`, `autoheader`, and `aclocal`. If the project is not already a libtool project then converting it to one (with `libtoolize`) may be more work than you wanted or needed. For their part, `autoheader` and `aclocal` should be run by `autoreconf` anyway, so it is redundant to run them separately. – John Bollinger Jan 04 '18 at 16:50
  • 1
    I've found that this error message usually indicates an unexpanded macro on the _previous_ line. – ptomato Jan 05 '18 at 04:34
  • 1
    This github issue is very helpful: https://github.com/openucx/ucx/issues/3540#issuecomment-495794266 (short story the error message is just VERY misleading) – olejorgenb Mar 08 '20 at 12:28

3 Answers3

5

How does one troubleshoot a Possibly undefined macro: AC_MSG_ERROR problem with Autotools?

In the first place, where possible, one should avoid the situation altogether by not rebuilding the build system. An Autotools build system is intended to not require rebuilding as a prerequisite to building the package, so the first course of action should always be to try ./configure; make without running the Autotools at all.

If you do need to rebuild the build system, which is sometimes necessary because even the best Autotools hacker cannot possibly account for all possible present and future build environments, then the first part of that is to ensure you have recent versions of the Autotools and to run autoreconf --install --force (which I see you are doing already). This ensures that everything is set up correctly for the versions of the Autotools that you have.

That brings us around to the actual question, about troubleshooting, and particularly about troubleshooting errors referencing standard Autoconf macros such as AC_MSG_ERROR. You have several tools and approaches available to you, among them:

  • Look at the configure.ac lines reported in the warnings, especially the lowest one, and at the preceding lines. This particular error indicates that text is being emitted into the output file that looks like an unexpanded macro name, so the problem often arises from incorrect quoting or unclosed macro argument lists.

    • It can be helpful to use an editor that will do parenthesis matching for you to enable you to easily verify where each macro's argument list really ends.
    • It can be especially helpful to use an editor that knows how to do code highlighting for Autoconf source files.

  • Examine the configure script that Autoconf outputs. Find where it starts to go wrong (in this case, the unexpanded macro names will help you find it), and correlate that and the preceding correct output with the contents of your configure.ac and of any external macro definitions it relies upon. That can help you pinpoint the locus of the error.

  • You can comment out Autoconf source lines with # or dnl in service to applying the bisection method for tracking down the erroneous line(s).

  • Run autoconf directly, with extra debugging-oriented options. For example,

    autoconf --verbose --force --warnings=all

    There is also a --debug option that preserves temporary files, but I suspect that it would be less useful for your purposes.

  • In certain cases it might be helpful to trace calls to one or more macros, by use of the --trace option, though I don't see that being so relevant to the particular errors you asked about. Note that tracing output takes the place of the configuration script that autoconf normally outputs.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • While it would be nice if we didn't have to rebuild autotools all the time, this is not always possible (e.g. if you're getting the sources directly from git, or from a github tagged tarball). It's also possibly a bad idea in general, as it's unfortunately very easy to obfuscate malicious code in a `configure` file :( – Diego Elio Pettenò Jan 17 '18 at 23:48
  • As i said, @DiegoElioPettenò, *where possible* one should avoid rebuilding the build system. As for not doing so being a bad idea, if you don't trust the software source then you oughtn't to be getting software from them at all. It's at least as easy to obfuscate malicious program source code as it is to obfuscate malicious configuration code, and doing the former can have much broader reach. – John Bollinger Jan 18 '18 at 14:01
  • 1
    As a Linux packager for 13 years, I disagree. Hiding malicious actions in `configure` or `Makefile.in` is easier because most people just don't even *look* at that code. And most people will also run `sudo make install` (when they don't run the whole build as root), which provides a higher surface of attack. – Diego Elio Pettenò Jan 18 '18 at 23:46
3

I think ptomato in the comments is the closest to the answer. Usually when AC_MSG_ERROR (which is a standard autoconf macro) is considered "undefined", the bug is to be found on the lines that precede the error itself. Not necessarily the previous line, but one of the lines above.

In this case, the error is at line 62, so I would go and look for the most recent non-default macro call.

There is a call to GTK_DOC_CHECK on line 39 but that is protected by a m4_ifdef so it should be safe, even if you didn't have gtkdoc-devel or similar packages installed.

On line 33 there is an unprotected call to AM_GNU_GETTEXT_VERSION, which my guess is where the problem lies. Make sure you have gettext-devel or equivalent package and try again.

Diego Elio Pettenò
  • 3,152
  • 12
  • 15
3

Try to install missed macros with :

 apt install autoconf-archive
Vadim Hapanchak
  • 52
  • 2
  • The macros that the error messages are complaining about belong to Autoconf itself. The autoconf-archive (site and package) provides third-party add-on macros, not Autoconf's basic ones. – John Bollinger Sep 21 '22 at 18:31
  • But works in my case.. so probably could help for someone else to.. – Vadim Hapanchak Sep 22 '22 at 19:48
  • If one is depending on having systemwide copies of the Autoconf archive macros, then that is a plausible way to obtain them. At least on suitably configured Debian-family systems, including Ubuntu. But that is not the situation presented in this question. This answer is not a good one *for the question posed*. – John Bollinger Sep 22 '22 at 19:56
  • Worked in my case too... – Ryan B. Oct 05 '22 at 10:44