如何解决“可能未定义的宏：AC_MSG_ERROR”答案

【问题标题】：How to troubleshoot "Possibly undefined macro: AC_MSG_ERROR"如何解决“可能未定义的宏：AC_MSG_ERROR”
【发布时间】：2018-06-14 02:20:08
【问题描述】：

我正在尝试从 GutHub 源构建 libpsl。它需要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
...

我找到了Possibly undefined macro: AC_MSG_ERROR 和AS_IF and AC_MSG_ERROR: error: possibly undefined macro，但猜测并没有解决我的问题。在过去的 4 个小时里，我一直在尝试猜测。

我想停止猜测并解决问题。我遇到的问题是，我找不到有关排除 Autotools 问题的信息或程序。授予，"troubleshoot" autoconf site:gnu.org。

我想出的最好的方法是使用-v 运行命令，但我没有看到复制general.m4 的尝试。如果我没记错的话，general.m4 提供了AC_MSG_ERROR，所以我应该看到它被访问了。所以我的程序有明显的差距或缺陷。并且文件存在：

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

如何解决 Autotools 的 Possibly undefined macro: AC_MSG_ERROR 问题？

【问题讨论】：

我觉得奇怪的是您手动调用libtoolize、autoheader 和aclocal。如果该项目还不是一个 libtool 项目，那么将其转换为一个（使用libtoolize）可能比您想要或需要的工作更多。对于他们来说，autoheader 和aclocal 无论如何都应该由autoreconf 运行，因此单独运行它们是多余的。
我发现这个错误信息通常表明 previous 行上有一个未扩展的宏。
这个 github 问题非常有帮助：github.com/openucx/ucx/issues/3540#issuecomment-495794266（短篇小说错误消息非常具有误导性）

标签： autotools autoconf m4

【解决方案1】：

如何解决可能未定义的宏：AC_MSG_ERROR Autotools 问题？

首先，在可能的情况下，应该通过不重建构建系统来完全避免这种情况。 Autotools 构建系统旨在不需要将重新构建作为构建包的先决条件，因此首先应始终尝试 ./configure; make 而不运行 Autotools。

如果您确实需要重建构建系统，这有时是必要的，因为即使是最优秀的 Autotools 黑客也无法解释所有可能的当前和未来构建环境，那么首先要确保您拥有最新版本的Autotools 并运行autoreconf --install --force（我看到你已经在这样做了）。这可确保为您拥有的 Autotools 版本正确设置所有内容。

这让我们回到了实际问题，关于故障排除，尤其是关于引用标准 Autoconf 宏（例如 AC_MSG_ERROR）的故障排除。您可以使用多种工具和方法，其中包括：

查看警告中报告的configure.ac 行，尤其是最低的行，以及前面的行。此特定错误表明正在将文本发送到看起来像未扩展的宏名称的输出文件中，因此问题通常由不正确的引用或未关闭的宏参数列表引起。
- 使用可为您进行括号匹配的编辑器会很有帮助，使您能够轻松验证每个宏的参数列表真正在哪里结束。
- 使用知道如何对 Autoconf 源文件进行代码突出显示的编辑器尤其有用。
检查 Autoconf 输出的 configure 脚本。找到它开始出错的地方（在这种情况下，未扩展的宏名称将帮助您找到它），并将该和前面的正确输出与您的 configure.ac 的内容以及它所依赖的任何外部宏定义相关联。这可以帮助您查明错误的位置。
您可以使用# 或dnl 注释掉Autoconf 源代码行，以应用二等分法来追踪错误行。
直接运行autoconf，带有额外的面向调试的选项。例如，
```
autoconf --verbose --force --warnings=all
```
还有一个--debug 选项可以保留临时文件，但我怀疑它对您的用途不太有用。
在某些情况下，使用--trace 选项跟踪对一个或多个宏的调用可能会有所帮助，尽管我认为这与您询问的特定错误无关。请注意，跟踪输出代替了autoconf 通常输出的配置脚本。

【讨论】：

虽然我们不必一直重建自动工具会很好，但这并不总是可能的（例如，如果您直接从 git 或从 github 标记的 tarball 获取源代码）。总的来说，这也可能是个坏主意，因为很遗憾很容易混淆configure 文件中的恶意代码:(
正如我所说，@DiegoElioPettenò，在可能的情况下应该避免重建构建系统。至于不这样做是一个坏主意，如果您不信任软件来源，那么您根本不应该从他们那里获取软件。混淆恶意程序源代码至少与混淆恶意配置代码一样容易，而且前者的影响范围更广。
作为一个 13 年的 Linux 打包者，我不同意。在configure 或Makefile.in 中隐藏恶意操作更容易，因为大多数人甚至都不查看该代码。而且大多数人也会运行sudo make install（当他们不以root身份运行整个构建时），这提供了更高的攻击面。

【解决方案2】：

我认为 cmets 中的 ptomato 最接近答案。通常当AC_MSG_ERROR（这是一个标准的autoconf 宏）被认为是“未定义的”时，可以在错误本身之前的行中找到错误。不一定是 previous 行，而是上面的行之一。

在这种情况下，错误在line 62，所以我会去寻找最近的非默认宏调用。

在line 39 上有一个对GTK_DOC_CHECK 的调用，但它受到m4_ifdef 的保护，因此它应该是安全的，即使您没有安装 gtkdoc-devel 或类似的软件包。

在line 33 上有一个对AM_GNU_GETTEXT_VERSION 的不受保护的调用，我猜这就是问题所在。确保您有 gettext-devel 或同等软件包，然后重试。

【讨论】：