构建是软件开发过程中最常见的活动之一，也是很容易被忽视的环节。规范以及高效的构建对软件开发过程而言是大有裨益的。C语言并非一门年轻的语言，其历史已甚为悠久了(相对于还年轻的IT领域^_^)。从C语言诞生以来，市面上存在的C语言应用何止千千万万。这些C应用的源码组织形式种类万千，从最简单的单个源文件，到复杂的诸如Apache httpd server这样庞大的Project。不过无论这些C应用的源码组织形态如何，构建都是这些应用开发过程中必不可少的一步。

伴随着C语言的普及，C语言应用的构建工具也逐渐发展起来，随着Project构建复杂性的增加，大致可分为四个阶段(个人观点)：
* 命令行构建
对于简单应用来说，其源文件数量一般较少，且可能都放在一个同目录下，构建这样的工程的最简单的方法就是直接在命令行上输入编译命令(诸如gcc -o foo foo.c bar.c)。这种方式在C诞生早期的简单应用或对于刚刚C入门朋友来说是最常见的。

* make工具
随着Project复杂程度的增加，使用命令行编译构建的难度日益加大，大家开始使用make工具。make工具的实质是帮助项目管理依赖关系。C应用构建的最终目标一般都是一个可执行文件，该文件一般是由所有源文件的目标文件以及依赖的第三方库链接后生成的，也就是说该文件依赖项目源文件的目标文件以及第三方库。我们可以将这种依赖关系用make工具指定的专用语法描述出来，形成Makefile文件。后续我们如果要构建该Project，只需敲入make即可。make工具会自动分析Makefile中的依赖关系，并执行依赖关系对应的命令，并最终完成构建。

* autotools
虽然make工具很好地解决了复杂Project的构建问题，但make本身的学习曲线也是很陡峭的，也就是说要为一个复杂的C应用编写Makefile脚本并非易事，特别是复杂Project中那更为复杂的依赖关系，可以让任一一个程序员望而却步。大家都看到了这一点，因此就有了autotools工具集的诞生。autotools工具集由autoconf、autoheader、automake和libtool等工具组成，其主要目标就是简化项目Makefile的编写。使用autotools，我们可以为C应用的Project自动生成Makefile，这显然是一个很大的进步，对于复杂的Project尤甚。

* 新兴的通用构建工具
虽然autotools的出现解决了一些C应用构建难的问题，但autotools自身使用起来也是略显复杂的。特别是它由若干工具组成，并需要这些工具一起配合才能完成一个Project的Makefile的编写和生成，学习这些工具本身也要耗费很多时间。随着一些脚本语言的流行，一些新兴的通用构建工具逐渐出现在大家的视线中，诸如Scons、rake等。这些新工具吸取了make等门槛较高、不易用的教训，利用脚本语言特有的性质打造出了更加简单易用的构建脚本，现在很多C应用都开始使用这些工具简化构建脚本编写了。

究竟是使用哪种构建工具，这还是取决于项目所处的"环境"，包括项目的复杂性，人员的平均技能水准等等。但有了构建工具还不足矣，我们再来看看关于C语言应用构建还有哪些应该关注的地方。

一、规范化项目源码组织
项目的源码组织是应该先于构建脚本实现的，因此良好的项目源码组织也有助于构建脚本的编写，同时也有利于组织内部的标准化和复用。但C应用的源码组织的确没有统一的标准，也没有最好可言，也许只有适不适合。下面就是我们所使用的一个典型的C应用(非公共库)源码组织示例：

Foo_proj/
    – Makefile
    – sub_proj1/
        – Make.rules(由buildc生成)
        – Makefile
        – include/
        – module1/
            – xx.c
            – Makefile
            – tests/
                – xx_test.c
                – Makefile
        – module2/
            … …
    – sub_proj2
        – Make.rules(由buildc生成)
        – Makefile
        – include/
        – module1/
            – xx.c
            – Makefile
            – tests/
                – xx_test.c
                – Makefile
 … …

针对这个示例有几个注意事项要说明一下：
a)
以前在很多Project中，都会包含一个顶层的(toplevel)Make.rules，这样的设计考虑无非是希望项目下的其他sub_proj可以复用该Make.rules，这看起来似乎方便了。但实际这样做是在各个子项目间建立了一层构建耦合关系：很多子项目都有个性化的构建需求，这样一来可能会频繁对该顶层Make.rules进行修改；或是当无法修改顶层Make.rules时子项目还是会在自己下面增加一个子Make.rules以满足构建的个性化需求。我们莫不如去掉顶层Make.rules，而在各个子项目中添加自己的Make.rules。特别是在有了buildc工具以后，每个子项目下的Make.rules都是自动生成的，这样不但不会增加太多的额外工作量，还从根本上去除了子项目间的一种耦合，完全可满足sub_proj的个性化的构建需求。

b) 顶层的Makefile依旧保留，一般作为一键构建整个项目时之用。顶层的Makefile实际来看就是将各个sub_proj串接起来，再说白些，就是遍历的调用各个sub_proj下的Makefile。

c) 针对每个module的单元测试代码与被测试的module代码存放在一起(比如放在module下面的tests目录下)，这样使得被测对象与测试代码物理上接近，易于源码的测试，同时逻辑上看也很紧凑。

二、构建执行的简单和高效
构建是一个频繁的日常开发活动，简单和高效是IT开发者对"构建"活动的两个基本要求。所谓"简单"就是尽量不让或少让我动手，懒惰的程序员们最多只是希望敲入一个命令就可以完成项目的所有构建，这就是我们所说的"一键化"。一键化从另一个角度来说也是一种"高效"，但"高效"更重要的含义则是指尽量缩短构建的时间。要想做到这点，一是需要一个清晰明了的构建脚本实现，把项目内部的各种依赖关系打理清楚，只作必要依赖，减少不必要的重复构建；第二则是选择一款高性能的构建工具，目前来看make本身的性能还是很棒的，一般来说还是强于scons这样以动态脚本语言实现的工具的，特别是再加上并行编译和分布式编译后，构建时间将大大缩短。

三、第三方依赖包的管理
在开源软件大行其道的今天，很多商业项目都或多或少的用到一些开源包，即使没有用到开源包，组织内部也可能存在项目间相互依赖的情况，比如：业务部门的应用很可能依赖基础研发部门提供的通用库，这样就出现了一个第三方依赖的管理的问题，这也是我们在进行构建设计过程中所不可忽视的一个重要方面。

关于第三方依赖包的管理，至少我是见识过如下几种方式：

* 将第三方依赖包的源码导入到你的项目，伴随项目一并构建
这样做的好处之一就是完整：大家在构建项目时无需东找西寻，依赖的代码就在项目库中。好处之二是便于一键构建，依赖包的源码就在项目中，可以任你"宰割"；第三则是便于在不同平台上移植，因为直接存储了源码，在每个平台都是依据所在的平台构建对应的版本。

不足之处：这样做会导致项目代码库庞大，构建时间漫长；另外也不便于第三方依赖包的更新升级。一旦第三方依赖包有bugfix或新feature，你可能需要手动的同步代码。一旦依赖的第三方包有很多的话，这可是一笔不小的工作量；最后每个项目都单独存储一份第三方依赖包会导致大量重复，重复可并不是一个好味道。

* 将第三方依赖包构建后的二进制文件放入项目代码库
这样做的好处在于提高了构建效率，节省了第三方依赖库自身的构建时间。但这样做的不足之处依然很多，直接存储源码方式的大多数不足都被该方式继承了下来，除此之外，这种方式还会导致在不同平台上构建难度的增加(不同平台上的包的二进制文件是不同的)。

* 对第三方依赖包进行集中单独管理
将各个项目所使用的第三方依赖库做统一集中管理，而不是放在每个项目中，并且只存储构建后的二进制文件而非源码。组织形式示例见下面：

3rds/
      – libevent/
           – 2.0.10/
              – README
              – source_code_package
              – sparc_32_solaris/
    - include/
    - lib/
              – sparc_64_solaris/
              – x86_64_solaris/
              – x86_64_linux/
           … …
      – netsnmp/
      … …

这种"分门别类"的第三方依赖包集中管理方式既有利于加速构建过程(直接用二进制，省下源码编译)，同时也便于依赖包的统一升级和管理(专人负责，通过版本号区分)。这种第三方依赖包的管理方式也是使用buildc构建辅助工具的前提。这种方式也是有缺点的，那就是需要有专人负责对该公共库进行管理，包括新版二进制包的制作与上传。

至于在具体项目中究竟采用哪种方式还需要根据project的具体情况作出权衡，如果你依赖的第三方包较小且很少，那方式一很适合，redis就是这么做的；如果你不要支持多平台，那么第二种方式也可行；对于组织而言，似乎第三种方式是规范、统一和一致的，这也是我推荐的方式。

四、适于与第三方工具集成
持续集成是公认的优秀实践，市面上有很多优秀的ci工具。持续集成的第一步就是构建，因此一个好的工程构建是应该能与ci工具很好结合在一起的，也就是说要充分考虑构建脚本与ci工具的结合。

一般来说持续集成工具判断成败与否的根据就是你委托ci工具执行的脚本的返回值。对于C应用构建过程来说，一般是make的返回值。0即成功，其他均为失败。对于单元测试用例的执行过程而言，也同样是此道理。C的单元测试集实际上就是一个个可执行程序，每个程序的返回值都是需要认真考量的，不能随意。如果你使用类似lcut这样的框架工具，你就完全可以通过框架工具来帮你完成用例执行返回值的设定。

良好的项目构建设计是项目迈向成功的重要一步。在日常开发工作中我们不仅仅要关注软件开发过程中的"前段"，比如需求、设计和编码；对"后段"的一些活动，诸如构建、测试和部署也要给予足够的关注。以上所讲仅是经验之谈，谈不上绝对正确，因为关于C应用构建的资料相对较少，也没有统一的标准，这里权当抛砖引玉了。

清晨，部门新来的一位小兄弟打来求助电话，说是系统启动的时候出现类似："ld.so.1: testmain: 致命的: 重定位错误: 文件./libtestshared.so: 符号static_add: 参照的符号没有找到"的错误。这个系统是05年开发的一个复用度很高的自研产品，后续项目只需在其基础上做少量二次开发工作即可满足新功能的要求。为了做到一定的通用性，我们使用了类似插件的框架，这样系统在启动的时候会根据配置加载一些'共享库'(.so文件)，而这个小同事反映的问题就出在这。

上面仅仅是一个引子，在写下本篇文章之前，这个问题已经被解决，我的那个小同事在连续奋战14个小时(从昨晚21:00到今天上午11:00)后，终于也可以安心踏上返回四川老家的火车了。事后，我深入的想了一下这个问题，觉得有必要说一下。

这里用一个简单的例子来重现一下这个问题吧。我们先来准备一个静态链接库(.a)和一个动态共享库(.so)，都比较简单，能反映出问题就行。

[静态库]
//teststatic.h
int static_add(int a, int b);

//teststatic.c
#include "teststatic.h"
int static_add(int a, int b) {
        return a+b;
}

编译静态库：
gcc -c teststatic.c
ar crv libteststatic.a teststatic.o

[动态共享库]
//testshared.h
int dynamic_add(int a, int b);

//testshared.c
#include "testshared.h"
#include "teststatic.h"
int dynamic_add(int a, int b) {
        return static_add(a, b);
}

编译共享库：
gcc testshared.c -fPIC -shared -o libtestshared.so

然后，我们再写一个测试桩程序，其主要功能就是：通过dlopen和dlsym在运行时动态加载libtestshared.so，然后得到符号dynamic_add的地址，完成计算功能。
#include
#include

typedef int (*PTR)(int, int);

int main() {
        void    *handle = NULL;
        char    *errinfo = NULL;
        PTR     ptr;
        int     rv;

        handle = dlopen("./libtestshared.so", RTLD_LAZY);
        if (handle == NULL) {
                errinfo = dlerror();
                printf("dlopen失败: %s\n", errinfo);
                return;
        }

        ptr = (PTR)dlsym(handle, "dynamic_add");
        if (ptr == NULL) {
                errinfo = dlerror();
                printf("dlsym失败: %s\n", errinfo);
                return;
        }

        rv = ptr(1,2);
        printf("rv = %d\n", rv);
}
编译：gcc -o testmain testmain.c -ldl -L./ -lteststatic
运行结果：ld.so.1: testmain: 致命的: 重定位错误: 文件./libtestshared.so: 符号static_add: 参照的符号没有找到，被杀掉。

通过运行结果分析：程序在启动时，链接程序并没有找到符号:static_add，无从知道其指令代码，所以报错。这个例子反映的就是我那个小同事犯的'错误'– 程序在加载阶段链接器无法resolve共享库里调用的其他函数符号。那为什么找不到呢？我们还需简单回顾一下程序启动阶段的一些事情。

程序启动后，由加载器(即常说的loader)将之加载到内存中，过程很复杂和繁琐，我们就说程序中的符号是如何resolved的(我是从John R.Levine的"Linkers & Loaders"一书中学到的一些皮毛)。加载阶段，加载器(很多工作由链接器完成)先进行自身的初始化，之后它会根据程序文件的头(Headers)中的信息，查找程序所需要的共享库(静态库是在编译期间就已经链接到程序本身中了)的名字，对于每一个共享库的名字，它都会在搜索路径下搜索该共享库是否存在，如果存在，则处理该共享库文件，处理包括：分配text和data段空间并进行映射，其符号表将被merge到主符号表里；如果该共享库文件依然有依赖的其他共享库，且该依赖的共享库在之前并未被load，则将该依赖的共享库加入到待加载的库列表中。

有人要说，上面的testmain程序与这个加载过程不同啊，testmain是用dlopen和dlsym在运行时而不是加载时加载.so的，其实按照John R.Levine的说法: "The two routines dlopen & dlsym are actually simple wrappers that call back into the dynamic linker"，也就是说：使用dlopen和dlsym的组合时，完成的事情和加载阶段链接器完成的事情是一样的。

那我们来看，testmain编译的时候是不依赖任何显式(C运行时和unix系统库等隐式的除外)的共享库的，那么在加载libtestshare.so时，遇到static_add这个符号时，就不知所措了。这里又有人要问了：编译testmain的时候不是链接了libteststatic.a这个库了吗，这个库里不是有static_add的符号吗？你可以nm testmain > dump.log看一下，看看dump.log中是否有static_add这个符号。其实细想一下也会知道：testmain.c中根本没有使用static_add，编译器当然不会无端将static_add的放入testmain的可执行文件中了，否则在unix系统下的每个用户级程序的'体格'都会极其庞大。

上面说过，因为testmain.c中没有使用static_add，所以不能动态加载so时，不能resolve这个符号，如果testmain.c中使用了static_add，那么程序就没有问题了吧？没错！看下面：
#include "teststatic.h"
… …
int main() {
        void    *handle = NULL;
        char    *errinfo = NULL;
        PTR     ptr;
        int     rv;
    
    rv = static_add(5, 6);
    printf("rv = %d\n", rv);

        … …

        rv = ptr(1,2);
        printf("rv = %d\n", rv);
}
这样一来，static_add就会体现在testmain的符号表里，作为testmain的一部分了。当运行时加载.so后，遇到static_add这个符号时，链接器就有据可依了。

又会有人问：我们不能要求所有.so中出现的符号在主程序中都要有吧？对，这样要求显然是无理的，那么如何是好呢？我们只能在编译.so时将这些符号静态链入.so，比如：gcc testshared.c -fPIC -shared -o libtestshared.so -L./ -lteststatic

我们可以通过nm命令看到链入静态库前后的不同：

未链入静态库时nm *.so，符号static_add处于UNDEF状态
[67]    |         0|       0|NOTY |GLOB |0    |UNDEF  |static_add
链入静态库后，nm *.so的结果：
[68]    |      1412|      36|FUNC |GLOB |0    |10     |static_add
static_add的代码被copy一份放到了.so中。

这里关于dlopen函数的第二个参数mode再多写两句。上面的例子中，我们传入的参数是RTLD_LAZY，什么意思呢？RTLD_LAZY是说：.so中的符号只有在其第一次使用的时候，才会由链接器计算出其实际地址，否则在.so加载时是不计算其实际地址的。原因也很简单：一个.so文件中可能有成百上千的符号，我们的程序也许只用到其中的一两个，如果加载时所有符号都要将其实际地址映射好，显然会降低运行时动态加载的性能。还是以testmain.c为例，如果代码中去掉对ptr(1,2)的调用，那么执行testmain是不会出错的。

dlopen中还提供了些许选项，比如：RTLD_NOW，从字面含义也可以猜测出来，其含义与RTLD_LAZY正相反，即.so加载时，其内部所有符号都要计算出实际地址。还以testmain.c为例：
handle = dlopen("./libtestshared.so", RTLD_NOW);
这时即使去掉对ptr(1,2)的调用，执行时会提示：dlopen失败: ld.so.1: testmain: 致命的: 重定位错误: 文件./libtestshared.so: 符号static_add: 参照的符号没有找到。

看来，共享库中的符号链接没有想象中的那么容易，使用的时候要'小心'。也许正是这些需要你投入和认真思考的问题才让使用C语言进行底层或系统开发更具魅力。