设为首页 友情链接
在线留言 发表文章
加入收藏 广告联系

刺猬首页

| 专案技术 | 网络技术 | 图形图象 | 网络编程 | 网页设计 | 操作系统 | 服务器 | 技术白皮书 | 在线实验室 | 刺猬论坛 |
小说专版  | 数据库 | 设计赏析 | 存储频道 | 网络安全 | 私服架设 |  Solaris | 网站评估 | PC维护技巧 | 下载中心 | 博 客 |
专   题: | Linux | java | cisco | 防病毒 | 刀片 | SOA | iscsi | ASP.NET | SQL | Oracle |
您现在的位置: IT公社 IT community >> Linux专题 >> Linux 软件开发 >> 教程正文 用户登录 新用户注册
专 题 栏 目
最 新 热 门
最 新 推 荐
相 关 文 章
Linux操作系统的内核编译…
重新编译Linux内核必要性…
让你的Linux内核重编译之…
重新编译Linux操作系统的…
编译内核以使其支持PS并…
编译支持NTFS的Linux系统…
配置、编译Linux系统内核…
快速编译Linux内核需要的…
VMware 中编译内核 2.4.…
Linux系统下广播程序制作…
  程序编译中如何调试configure         
程序编译中如何调试configure
 

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

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

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


清单 1. 每个系统的代码


    #ifdef SUNOS4 || NEXT || NETBSD || FREEBSD || OPENBSD

    #include <string.h>

    #else

    #include <strings.h>

    #endif

每个特性的代码如下:


清单 2. 每个特性的代码


    #ifdef HAS_STRING_H

    #include <string.h>

    #else

    #include <strings.h>

    #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 <X11/X.h>
int main(void) { return 0; }

现在,如果您用编译器来尝试进行编译,那么只有当 <X11/X.h> 在编译器的 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 脚本设置一些非常详细的变量,而且如果是在交叉编译,您很可能得做一些非常特别的事情。 CCconfigure 用于指定 C 编译器的变量,通过指定 CC 的值可以解决许多问题。如果您指定了编译器, configure 将使用那个编译器而不用去猜测需要使用哪一个。要注意的是,这样您可以在命令行中指定选项和标记。例如,如果您希望编译时支持调试符号,尝试:

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

(这里假定您使用的是 sh 系列的 shell;在 csh 中,用 setenv 来设置环境变量 CC 。)

阅读 config.log

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


清单 3. 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)

Linux联盟收集整理

频道声明:本频道的文章除部分特别声明禁止转载的专稿外,可以自由转载.但请务必注明出出处和原始作者 文章版权归本频道与文章作者所有.对于被频道转载文章的个人和网站,我们表示深深的谢意。

原始作者:佚名 录入时间:2007-2-4 20:22:20
信息来源:不详 投稿信箱:itqoo@126.com
教程录入:itqoo    责任编辑:itqoo 
  • 上一个教程:

  • 下一个教程:
  • 【字体: 】【发表评论】【加入收藏】【告诉好友】【打印此文】【关闭窗口
      网友评论:(只显示最新10条。评论内容只代表网友观点,与本站立场无关!)
    - 关于我们 - 合作伙伴 - 友情链接 - 广告刊登 - 投稿热线 - 在线留言版权声明联系方式 -
    IT公社版权所有 粤ICP备05127012号
    Copyrigh@2005-2006 itqoo.com.Inc All Rights Reserved  推荐分辨率 1024*768
    联系站长:E-Mail:itqoo@126.com     MSN:urchincc@hotmail.com    QQ:点击这里给我发消息
    特别感谢:亿太网络提供空间支持