调试configure

通常，在软件包的 README 文件中只能找到非常简单的“编译说明：运行 configure，然后运行 make”。但是，这样行不通时怎么办？在本文中，Peter Seebash 讲述了当自动的配置脚本失效时应该如何去做——以及作为开发者您应如何尽量避免这种错误。毕竟，如果您的程序无法编译，其结果将和您的程序编译后不能运行一样，您的用户会减少。

现在许多开放源代码的程序都会附带有 configure 脚本。这种脚本的用途之一是自动进行对目标新系统的猜测过程。在过去，程序会附带一个 Makefile 文件，这个文件中有 6 个不同的编译标记和选项，但只会用到一个，其余全部注释掉，并且会有一个注解，告诉您“为您的系统选择合适的标记”。如果配置选项更复杂，可能还会有一个名为 config.h 的长长的 C 头文件，其中包含一些要设置的标记，这依赖于主机系统变量。

第一个方法很简单，在代码中使用 #ifdef 以支持两种系统，例如 BSD 和 System V。由于 Unix 的类型的增加，更为实用的方法是对每一个特性使用 #ifdef 。每个系统的代码如下：

    #ifdef SUNOS4 || NEXT || NETBSD || FREEBSD || OPENBSD
    #include 
    #else
    #include 
    #endif

每个特性的代码如下：

    #ifdef HAS_STRING_H
    #include 
    #else
    #include 
    #endif

后者更容易适应新系统，但需要开发者进行大量的工作。由于现在有太多可能的目标系统，因此，第二种方法对用户来说帮助很大，不仅仅是可以自动生成配置头文件。完成这项任务的一种方法是使用 GNU autoconf 代码来生成 configure 脚本。这个脚本会去执行必要的测试，并创建一个具有适当值的配置头文件。

这种脚本的另一个功能是以一致的方式设置预定义的变量。用手工编辑标记一直存在一个问题，即修改了 Makefile 文件（比如将其安装到 /usr/gnu 而不是 /usr/local 目录下）却忘记修改头文件中相应的值。当然，这样的结果是，编译后的程序不知道到哪里去寻找它们自己的数据文件。使用 configure 脚本的一个好处是可以自动完成一致的安装（如果维护者做得没错的话）。

开发人员请注意，一个好的 configure 脚本的另一个好处在于，它会允许用户指定一些个人偏好，例如使用 /usr/gnu 而不是 /usr/local。

最后， configure 脚本可以完成大量猜测工作，即安装了哪些可选软件包或缺少哪些必要条件。例如，一个设计运行于 X Window System 的程序需要知道 X 安装在哪里，或者甚至要知道 是否安装了 X。

这些如何成为可能？

回页首

configure 的许多功能实现机制其实很简单。为了能切身体会，您可以设计一个小测试程序，这个程序当且仅当期望的条件得到满足时才可以编译。将它保存在一个临时文件中，然后尝试编译它。例如，假定您想知道 X Windowing System 是否安装在 /usr/X11R6 目录下。一种方法是做一个如下的测试程序：

#include
int main(void) { return 0; }

现在，如果您用编译器来尝试进行编译，那么只有当 在编译器的 include 路径中时，编译才会成功。因此，对每一个您认为 X 可能安装到的目录，可以将对应的 (directory)/include 加入到编译器的 include 路径中，并尝试对程序进行编译。如果采用某个值时示例文件可以编译，那么您就得到了正确的 include 路径。

请注意在 autoconf 中已经预定义了各种测试程序。如果可能，就直接使用这些测试程序，而不用自己去写。这样有很多好处。首先， autoconf 的新版本会改进这些测试程序，修正它们的错误，否则您将不得不自己去做这些工作。其次，这样会节省您的时间。当然，更好的方法是完全避免测试。如果您确认某一个测试是没有必要的（例如，即使机器字节多于 8 位也仍需要使 sizeof(char) 为 1），您可以完全不去进行这个测试。

有一些测试是功能测试；它不足以确定是否存在一个名为 memcmp() 的函数，它的语义必须正确。通常，这些测试用于只是在一两个平台上被注意到的非常不明显的错误。这些测试实际上会去运行测试程序，并检查它的输出。测试程序遵循标准的 Unix 习惯：如果测试通过则返回值为 0，如果失败则返回一个非 0 值。

一旦您有了足够的测试程序，您可以用它们来自动确定必需的编译标记和定义，以将它们放到头文件的某个地方。通常， configure 脚本会允许用户给出部分或全部已知的条件，而不是让脚本自己去猜测。

来看一个特例，假定，系统的 broken memmove() 出现了问题。如果您不知道它现在有一个只会影响少部分程序的 bug，您可能会编译一个程序并将其发布为产品，而没有意识到这样您将会遇到偶然的灾难性错误。

在许多情况下，一个冗长而复杂的 configure 脚本的最终结果是这样的：目标系统提供了这个程序用到的每一个标准特性，而且它们正确工作。在这种情况下为什么不手工去设置这些标记呢？这对开发者来说是可行的，而对众多用户来说就不可以了。用户可能不会知道到他们的 Linux 版本存在特定的 bug。他们可能不知道已经安装了哪些软件包，或者安装到了何处。脚本帮那些最需要帮助的人来完成大部分的例行公事的工作。当脚本出错时，引发的额外工作的代价可能不会太大。

回页首

既然您已经基本上了解了 configure 都做了些什么工作，您可以开始寻找错误了。有两种可能的 configure 错误。一种是 configure 是正确的，而您的系统缺少必要的先决条件。绝大多数情况下， configure 脚本会正确诊断出这种错误。更为麻烦的情况是 configure 本身的错误。这样的结果或者是不能生成配置，或者生成一个不正确的配置。

当 configure 的猜测无误，而您缺少先决条件时，您所要做就是要满足缺少的那些先决条件。当您找到并安装好后，再重新运行那个报告缺少先决条件的 configure 脚本，就可以成功了。（不要忘记删除 config.cache 文件，这个文件缓存了上一次测试的结果；您应该让 configure 从头开始。）

如果您正在开发 configure 脚本，您需要确保您给出的错误消息有意义。如果您测试的是一个函数，而这个函数是一个常见的可添加的软件包的一部分，那么不要告诉用户缺少的函数的名称 —— 告诉用户他们需要的软件包。确保将先决条件信息写入 README 文件中。并且，请一定要告诉人们您测试使用的其他软件包的版本号。

当然，即使在先决条件需要的软件安装以后，configure 脚本可能还是找不到新安装的程序。在这种情况下，您又回到了当 configure 猜测错误时应该如何去做。

无论何时，当 configure 失败时您首先要做的是运行 configure -h ，并检查参数列表。如果它找不到您确认已经安装的库，您可能可以指定到另一个位置来找到这个库。您还可以禁用和启用某些特性。例如，用于 Angband （一个 Roguelike 游戏）的 configure 脚本有一个可选的标记 —— enable-gtk ，以告诉脚本在编译时启用 GTK 支持。如果没有这个标记，编译时根本不会去尝试。

如果您的系统配置得比较奇怪，您可能不得不为 configure 脚本设置一些非常详细的变量，而且如果是在交叉编译，您很可能得做一些非常特别的事情。 CC 是 configure 用于指定 C 编译器的变量，通过指定 CC 的值可以解决许多问题。如果您指定了编译器， configure 将使用那个编译器而不用去猜测需要使用哪一个。要注意的是，这样您可以在命令行中指定选项和标记。例如，如果您希望编译时支持调试符号，尝试：

CC="gcc -g -O1" ./configure

（这里假定您使用的是 sh 系列的 shell；在 csh 中，用 setenv 来设置环境变量 CC 。）

当 configure 脚本运行时，它会创建一个名为 config.log 的文件，其中记录的是测试日志和得到的结果。例如，一个典型的 config.log 片断如下：

    configure:2826: checking for getpwnam in -lsun
    configure:2853: gcc -o conftest -g -O2 -fno-strength-reduce conftest.c -lsun >&5
    ld: cannot find -lsun
    configure:2856: $? = 1
    configure: failed program was:
    (a listing of the test program follows)

如果我的系统中， -lsun 应该提供 getpwnam() ，我应该可以使用命令行来对其进行确切检查，然后再使用测试程序。只需进行少量这样的调试，我就可以根据得到的信息来修改 configure 脚本。请注意有帮助的行号；这个测试从 configure 脚本的第 2,826 行开始。（如果您是一个 shell 程序员，您可能会喜欢在阅读 configure 脚本片断时打印出行号；在 shell 中 $LINENO 不能自动地被扩展为合理值，脚本使用 sed 创建一个包含有行号的自身拷贝！）

当一个测试失败或者得到意外的结果时，最好先去读一读日志文件。请注意，有时测试失败仅仅是因为上一个测试的失败，这种失败实际上并不重要。例如， configure 可能会因为找不到一个您闻所未闻的库而退出，而这可能是因为测试标准 C 库中某个功能的程序失败而导致无法找到那个库。在这种情况下，只需要解决第一个问题，第二个问题也就不会再出现了。

在其他一些情况下， configure 可能会偶而出现猜测错误。一种情况是测试程序设计不正确而可能在一些系统中编译失败。例如，考虑如下用于判断 strcmp() 函数可用性的测试程序：

    extern int strcmp();
    int main(void) {
                    strcmp();
    }

编写这个程序是为了避免使用 头文件。这样做的意图是，如果 strcmp() 在库中可以找到，程序将可以被正确地编译和链接；如果没有找到，链接器将不能解析到 strcmp() 的引用，程序编译就会失败。

在 UnixWare 编译器的某一个版本中，对 strcmp() 的引用被自动转换为 Intel 处理器自己的字符串比较指令。这个过程只是将传递到 strcmp() 的参数替换到一行汇编代码中。不幸的是，前面的例子程序调用 strcmp() 时没有给出参数，因此生成的汇编代码无效，从而导致编译失败。实际上您可以使用系统中的 strcmp() ，但是测试程序错误地认为缺少这个函数。

当 autoconf 的目标为主流平台（特别是各种 Linux，但是还包括主要的 Unix 发行版本）时，极少出现有 bug 的测试，这种有 bug 的测试通常是在那些没用被广泛测试过的平台或编译器上运行测试的结果。例如，UnixWare 上的 gcc 不会发生前面的 bug；只是在使用系统本身的开发包进行编译时才会发生。通常，最简单的解决办法是在 configure 中注释掉相应的测试，并直接设置出问题的环境变量。

有时 configure 前阶段选择的编译器标记可以链接可执行文件，但最终生成的可执行文件却不能运行，这是一个特别致命的错误。这会导致测试无缘无故地失败。例如，如果您使用的链接器命令是错误的，虽然您可能会正确地进行了链接，但却不能运行。到完成本文时， configure 脚本还不能发现这一错误，所以只有那些需要目标程序运行的测试才会报告失败。这对调试来说是非常不可思议的，但是通过 config.log 脚本可以弄明白是哪里出了问题。例如，在一个测试系统中，我得到了这样的输出：

 
    configure:5644: checking for working memcmp
    configure:5689: gcc -o conftest -g -O2 -fno-strength-reduce
        -I/usr/X11R6/include    -L/usr/X11R6/lib conftest.c -lXaw -lXext
        -lSM -lICE -lXmu -lXt -lX11 -lcurses  >&5
    configure:5692: $? = 0
    configure:5694: ./conftest
    Shared object "libXaw.so.7" not found
    configure:5697: $? = 1
    configure: program exited with status 1

真正错误在于，编译器需要一个单独的标记来告诉它 /usr/X11R6/lib 需要在搜索目录列表中出现，这样在运行时才可以找到动态链接库。无论如何，这是第一个这样的测试，它真正运行编译过的测试程序，而不是程序编译成功后就停止。这是一个非常精妙的问题。

在这个系统中，解决的方法是添加

-Wl,-R/usr/X11R6/lib

到 CFLAGS 变量中。命令行：

$ CFLAGS="-Wl,-R/usr/X11R6/lib" ./configure

允许 configure 正确地运行这个测试。

这对交叉编译尤其不利，因为您可能不能运行实际上是由交叉编译器创建的可执行程序。最近的 autoconf 版本都尽量避免要求测试程序实际运行的测试。

使用 configure 脚本的另一个常见的问题是，如果一个特定的软件包安装到了一个非常规的位置， configure 将无法找到它。好的 configure 脚本通常允许您指定所需要的文件的路径，因为它们可能被安装到与众不同的位置。例如，许多 configure 脚本用一个标准的方法来告诉脚本到何处去寻找 X 库：

    X features:
      --x-includes=DIR    X include files are in DIR
      --x-libraries=DIR   X library files are in DIR

如果这样仍不行，您还可以尝试使用完全强制的方法：指定需要的编译器标记为您的 CC 环境变量或者是 CFLAGS 环境变量的一部分。

如果开发者给出了 autoconf 用于生成 configure 脚本的 configure.in 文件，一个工作区将运行最新版本的 autoconf 。可能这样就可以了，但即使不能很好地工作，这也可以解决一些问题。这样做的目的是更新用到的特定测试；它在旧版本的 configure 中可能就是一个引发问题的 bug。就此而言，如果您是这种情形下的开发者，请一定要发布您所用到的 configure.in 文件。

如果您经常要反复调整您传递到 configure 的参数，而且您并不擅长 shell 命令行编辑，那么可以做一个包装器脚本，这个脚本以适当的参数调用 configure 。经过一些调整和一些失败的测试后，您的脚本可能会是这样：

    ./configure --with-package=/path/to/package \
       --enable-widget \
       --disable-gizmo \
       --with-x=29 \
       --with-blah-blah-blah
       CFLAGS="-O1 -g -mcpu=i686 -L/usr/unlikely/lib \
          -I/usr/unlikely/include -Wl,-R/usr/unlikely/lib"

相对于一遍又一遍地在命令行中输入，将脚本放在一起将很方便 —— 而且以后您还可以引用它，或者将它的一个拷贝寄给别人。

回页首

一分预防胜似十分治疗。要使 configure 脚本工作的最好方法就是在生成它的时候尽力确保它不会出错。

当尝试构建一个健壮的 configure 脚本时，最需要注意的实际上很简单。永远不要去测试那些您并不真正需要的内容。不要测试 sizeof(char) ；因为在 C 中 sizeof 操作符返回字符大小的对象，以用来保存一些内容， sizeof(chare) 永远是 1 （即使是在那些字符位数大于 8 的那些机器上）。绝大部分情况下，没有理由去测试是否有权使用自 1989 版本标准出现以后的 ANSI/ISO C 中的函数或者标准的 C 头文件是否可用。更糟的是当标准的特性存在时还去测试非标准的特性。不要测试 是否可用；您不需要用它。如果您需要用 malloc() ，请用 。

在许多情况下，相对于进行广泛的测试以找出使用的是哪一个特性，简单地除去对这个不明显特性的依赖要可靠得多。可移植的程序并不难写，十年前就已经有了。

最后，尽量确保您使用的是最新版本的 autoconf 。bug 会得到极好的修正；很可能旧版本 autoconf 存在 bug，而在新一些的版本中这个 bug 就已经不复存在了。