程序编译中怎么样调试configure

程序编译中怎么样调试configure

来源： IBM DW中国 作者： Peter Seebach　 时间： 2007-04-22 点击： <script src="http://www.linux-cn.com/plus/count.php?aid=9657&mid=&view=yes"></script> [ 收藏 ] [ 投稿 ]

<script src="http://www.linux-cn.com/plus/ad_js.php?aid=24"></script> <script type="text/javascript"><!-- google_ad_client = "pub-5499099499828942"; /* 300x250, 创建于 08-10-8 */ google_ad_slot = "1695340614"; google_ad_width = 300; google_ad_height = 250; //--> </script> <script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"> </script> <script src="http://pagead2.googlesyndication.com/pagead/expansion_embed.js"></script> <script src="http://googleads.g.doubleclick.net/pagead/test_domain.js"></script> <script>window.google_render_ad();</script>

，但是测试程序错误地认为缺少这个函数。

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

编译器不真正工作

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

清单 5. 测试 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 版本都尽量避免要求测试程序实际运行的测试。

找到缺少的库和 include

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

清单 6. 寻找 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 。经过一些调整和一些失败的测试后，您的脚本可能会是这样：

清单 7. 包装器脚本

./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 脚本工作的最好方法就是在生成它的时候尽力确保它不会出错。

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