C++程序从编译到链接

C++程序从编译到链接然后再到调用的整个过程如下。

只是个人最近观点，希望能与志同道合的同学一起讨论。

 

注：这里只是研究C++的主流编译过程，与Java没有任何关系，因为使用的技术完全不一样（Java是编译和解释结合的语言）。并且由于不同的编译器厂商对于程序的编译过程不尽相同，但是主要流程还是一样的。

 

其实长久以来我就一直很不清楚obj文件的内容到底是什么，有人说是汇编，有人说是机器语言。如果是机器语言的话，那编译的过程是怎样加入操作系统信息的呢？因为这个问题的不断扩展和困扰，便决定彻底研究一下，网上几乎找不到相关资料，作者参照了基本系统编程的书籍后自行整理而来，数目见底，仅供参考，欢迎讨论。

 

一个C++工程中会存在cpp文件，头文件，库文件。

 

1． 首先经历的是预处理过程，将头文件加载进来，并且将各种#define信息代入。这时会见不到头文件，工程经过处理后会生成以cpp文件为基础的编译单元。有人可能会问那么头文件到哪里去了。其实头文件将cpp文件中的#include替换掉了。因此在以后的编程中需要严格注意include的先后顺序。因为C++语言是一种很注重申明的语言，为什么会这样这与程序的编译过程和链接过程的算法有关。貌似话题有点转远了，其实在这个阶段是生成一个个独力的编译单元。

 

2． 在编译单元生成之后，便是将编译单元进行编译，其实对于主流的编译其实存在两个阶段，首先是生成汇编语言，然后使用汇编器生成机器语言。其实这里要讲解的是汇编语言怎么变成机器语言的呢。机器语言顾名思义就是0101的二进制代码。对于一个类似于MOV AX，BX（这里写的是Intel 80x86的汇编代码，其实几乎每一种不同架构的芯片的汇编语言不怎么一样）的代码而言就是将MOV和AX和BX原封不动的用0101替换掉，如MOV代码是35的话AX为01，BX为10的话翻译的机器代码就是350110，二进制也就是001101010000000100010000。

 

3． 接下来的任务是链接。链接的过程如下所示：

因为篇幅太长，请看附件。

其实链接的任务是生成可执行文件。

其实我的一些不确认也就在这个地方。其实每一个程序都肯定有操作系统的一些信息，比如说程序的运行环境是DOS还是Windows程序，程序的大小等。我认为编译的整个过程中应该是在最后生成可执行文件的时候加入的。

 

以上便是对于编译，链接的整个过程。个人意见，仅作参考。

 

参考资料：

1. 《Thinking in C++》 Bruce Eckel 机械工业出版社

2. 《高级语言程序设计》 谭浩强 清华大学出版社

3. 《计算机组成结构化方法》 Andrew S. Tanenbaum 机械工业出版社

4. 《计算机组成与设计 硬件/软件接口》 David A. Patterson John L. Hennessy 机械工业出版社

 

附件：链接器的使用

许多 Visual C++ 的使用者都碰到过 LNK2005:symbol already defined 和 LNK1169:one or more multiply definedsymbols found 这样的链接错误，而且通常是在使用第三方库时遇到的。对于这个问题，有的朋友可能不知其然，而有的朋友可能知其然却不知其所以然，那么本文就试图为大家彻底解开关于它的种种疑惑。

 

大家都知道，从 C/C++ 源程序到可执行文件要经历两个阶段 :

 

(1) 编译器将源文件编译成汇编代码，然后由汇编器 (assembler) 翻译成机器指令 ( 再加上其它相关信息 ) 后输出到一个个目标文件 (object file, VC 的编译器编译出的目标文件默认的后缀名是 .obj) 中；

 

(2) 链接器 (linker) 将一个个的目标文件 ( 或许还会有若干程序库 ) 链接在一起生成一个完整的可执行文件。

 

    编译器编译源文件时会把源文件的全局符号 (global symbol) 分成强 (strong) 和弱 (weak) 两类传给汇编器，而随后汇编器则将强弱信息编码并保存在目标文件的符号表中。那么何谓强弱呢？编译器认为函数与初始化了的全局变量都是强符号，而未初始化的全局变量则成了弱符号。比如有这么个源文件 :

 

extern int errorno;

 

int buf[2] = {1,2};

 

int *p;

 

int main()

{

  return 0;

}

 

其中 main 、 buf 是强符号， p 是弱符号，而 errorno 则非强非弱，因为它只是个外部变量的使用声明。

 

有了强弱符号的概念，我们就可以看看链接器是如何处理与选择被多次定义过的全局符号 :

 

规则 1: 不允许强符号被多次定义 ( 即不同的目标文件中不能有同名的强符号 ) ；

 

规则 2: 如果一个符号在某个目标文件中是强符号，在其它文件中都是弱符号，那么选择强符号；

 

规则 3: 如果一个符号在所有目标文件中都是弱符号，那么选择其中任意一个；

 

    由上可知多个目标文件不能重复定义同名的函数与初始化了的全局变量，否则必然导致 LNK2005 和 LNK1169 两种链接错误。可是，有的时候我们并没有在自己的程序中发现这样的重定义现象，却也遇到了此种链接错误，这又是何解？嗯，问题稍微有点儿复杂，容我慢慢道来。

 

    众所周知， ANSI C/C++ 定义了相当多的标准函数，而它们又分布在许多不同的目标文件中，如果直接以目标文件的形式提供给程序员使用的话，就需要他们确切地知道哪个函数存在于哪个目标文件中，并且在链接时显式地指定目标文件名才能成功地生成可执行文件，显然这是一个巨大的负担。所以 C 语言提供了一种将多个目标文件打包成一个文件的机制，这就是静态程序库 (static library) 。开发者在链接时只需指定程序库的文件名，链接器就会自动到程序库中寻找那些应用程序确实用到的目标模块，并把 ( 且只把 ) 它们从库中拷贝出来参与构建可执行文件。几乎所有的 C/C++ 开发系统都会把标准函数打包成标准库提供给开发者使用 ( 有不这么做的吗？ ) 。

 

    程序库为开发者带来了方便，但同时也是某些混乱的根源。我们来看看链接器是如何解析 (resolve) 对程序库的引用的。

 

在符号解析 (symbol resolution) 阶段，链接器按照所有目标文件和库文件出现在命令行中的顺序从左至右依次扫描它们，在此期间它要维护若干个集合:

 

(1) 集合 E 是将被合并到一起组成可执行文件的所有目标文件集合；

 

(2) 集合 U 是未解析符号 (unresolved symbols ，比如已经被引用但是还未被定义的符号 ) 的集合；

 

(3) 集合 D 是所有之前已被加入到 E 的目标文件定义的符号集合。一开始， E 、 U 、 D 都是空的。

 

链接器的工作过程：

 

(1): 对命令行中的每一个输入文件 f ，链接器确定它是目标文件还是库文件，如果它是目标文件，就把 f 加入到 E ，并把 f 中未解析的符号和已定义的符号分别加入到 U 、 D 集合中，然后处理下一个输入文件。

 

(2): 如果 f 是一个库文件，链接器会尝试把 U 中的所有未解析符号与 f 中各目标模块定义的符号进行匹配。如果某个目标模块 m 定义了一个 U 中的未解析符号，那么就把 m 加入到 E 中，并把 m 中未解析的符号和已定义的符号分别加入到 U 、 D 集合中。不断地对 f 中的所有目标模块重复这个过程直至到达一个不动点 (fixed point) ，此时 U 和 D 不再变化。而那些未加入到 E 中的 f 里的目标模块就被简单地丢弃，链接器继续处理下一输入文件。

 

(3): 如果处理过程中往 D 加入一个已存在的符号 ，或者当扫描完所有输入文件时 U 非空，链接器报错并停止动作。否则，它把 E 中的所有目标文件合并在一起生成可执行文件。

 

    VC带的编译器名字叫 cl.exe ，它有这么几个与标准程序库有关的选项 : /ML 、 /MLd 、 /MT 、 /MTd 、 /MD 、 /MDd 。这些选项告诉编译器应用程序想使用什么版本的 C 标准程序库。 /ML( 缺省选项 ) 对应单线程静态版的标准程序库 (libc.lib) ； /MT 对应多线程静态版标准库 (libcmt.lib) ，此时编译器会自动定义 _MT 宏； /MD 对应多线程 DLL 版 ( 导入库 msvcrt.lib ， DLL 是 msvcrt.dll) ，编译器自动定义 _MT 和 _DLL 两个宏。后面加 d 的选项都会让编译器自动多定义一个 _DEBUG 宏，表示要使用对应标准库的调试版，因此 /MLd 对应调试版单线程静态标准库 (libcd.lib) ， /MTd 对应调试版多线程静态标准库 (libcmtd.lib) ， /MDd 对应调试版多线程 DLL 标准库 ( 导入库 msvcrtd.lib ， DLL 是 msvcrtd.dll) 。虽然我们的确在编译时明白无误地告诉了编译器应用程序希望使用什么版本的标准库，可是当编译器干完了活，轮到链接器开工时它又如何得知一个个目标文件到底在思念谁？为了传递相思，我们的编译器就干了点秘密的勾当。在 cl 编译出的目标文件中会有一个专门的区域 ( 关心这个区域到底在文件中什么地方的朋友可以参考 COFF 和 PE 文件格式 ) 存放一些指导链接器如何工作的信息，其中有一种就叫缺省库 (default library) ，这些信息指定了一个或多个库文件名，告诉链接器在扫描的时候也把它们加入到输入文件列表中 ( 当然顺序位于在命令行中被指定的输入文件之后 ) 。说到这里，我们先来做个小实验。写个顶顶简单的程序，然后保存为 main.c :

 

/* main.c */

 

int main() { return 0; }

 

用下面这个命令编译 main.c( 什么？你从不用命令行来编译程序？这个 ......) :

 

cl /c main.c

 

/c 是告诉 cl 只编译源文件，不用链接。因为 /ML 是缺省选项，所以上述命令也相当于 : cl /c /ML main.c 。如果没什么问题的话 ( 要出了问题才是活见鬼！当然除非你的环境变量没有设置好，这时你应该去 VC 的 bin 目录下找到 vcvars32.bat 文件然后运行它。 ) ，当前目录下会出现一个 main.obj 文件，这就是我们可爱的目标文件。随便用一个文本编辑器打开它 ( 是的，文本编辑器，大胆地去做别害怕 ) ，搜索"defaultlib" 字符串，通常你就会看到这样的东西 : "-defaultlib:LIBC -defaultlib:OLDNAMES" 。啊哈，没错，这就是保存在目标文件中的缺省库信息。我们的目标文件显然指定了两个缺省库，一个是单线程静态版标准库 libc.lib( 这与 /ML 选项相符 ) ，另外一个是 oldnames.lib( 它是为了兼容微软以前的 C/C++ 开发系统 ) 。

 

VC 的链接器是 link.exe ，因为 main.obj 保存了缺省库信息，所以可以用

 

link main.obj libc.lib

 

或者

 

link main.obj

 

来生成可执行文件 main.exe ，这两个命令是等价的。但是如果你用

 

link main.obj libcd.lib

 

的话，链接器会给出一个警告 : "warning LNK4098: defaultlib "LIBC" conflicts with useof other libs; use /NODEFAULTLIB:library" ，因为你显式指定的标准库版本与目标文件的缺省值不一致。通常来说，应该保证链接器合并的所有目标文件指定的缺省标准库版本一致，否则编译器一定会给出上面的警告，而 LNK2005 和 LNK1169 链接错误则有时会出现有时不会。那么这个有时到底是什么时候？呵呵，别着急，下面的一切正是为喜欢追根究底的你准备的。

 

    建一个源文件，就叫 mylib.c ，内容如下 :

 

/* mylib.c */

 

#include <stdio.h>

 

void foo()

{

  printf("%s","I am from mylib!\n");

}

 

用

 

cl /c /MLd mylib.c

 

（ ML 要是大写的，否则不认。）

 

命令编译，注意 /MLd 选项是指定 libcd.lib 为默认标准库。 lib.exe 是 VC 自带的用于将目标文件打包成程序库的命令，所以我们可以用

 

lib /OUT:my.lib mylib.obj

 

将 mylib.obj 打包成库，输出的库文件名是 my.lib 。接下来把 main.c 改成 :

 

/* main.c */

 

void foo();

 

int main()

{

   foo();

  return 0;

}

 

用

 

cl /c main.c

 

编译，然后用

 

link main.obj my.lib

 

进行链接。这个命令能够成功地生成 main.exe 而不会产生 LNK2005 和 LNK1169 链接错误，你仅仅是得到了一条警告信息 :"warningLNK4098: defaultlib "LIBCD" conflicts with use of other libs; use/NODEFAULTLIB:library" 。我们根据前文所述的扫描规则来分析一下链接器此时做了些啥。

 

    一开始 E 、 U 、 D 都是空集，链接器首先扫描到 main.obj ，把它加入 E 集合，同时把未解析的 foo 加入 U ，把 main 加入 D ，而且因为 main.obj 的默认标准库是 libc.lib ，所以它被加入到当前输入文件列表的末尾。接着扫描 my.lib ，因为这是个库，所以会拿当前 U 中的所有符号 ( 当然现在就一个 foo) 与 my.lib 中的所有目标模块 ( 当然也只有一个 mylib.obj) 依次匹配，看是否有模块定义了 U 中的符号。结果 mylib.obj 确实定义了 foo ，于是它被加入到 E ， foo 从 U 转移到 D ， mylib.obj 引用的 printf 加入到 U ，同样地， mylib.obj 指定的默认标准库是 libcd.lib ，它也被加到当前输入文件列表的末尾 ( 在 libc.lib 的后面 ) 。不断地在 my.lib 库的各模块上进行迭代以匹配 U 中的符号，直到 U 、 D 都不再变化。很明显，现在就已经到达了这么一个不动点，所以接着扫描下一个输入文件，就是 libc.lib 。链接器发现 libc.lib 里的 printf.obj 里定义有 printf ，于是 printf 从 U 移到 D ，而 printf.obj 被加入到 E ，它定义的所有符号加入到 D ，它里头的未解析符号加入到 U 。链接器还会把每个程序都要用到的一些初始化操作所在的目标模块 ( 比如 crt0.obj 等 ) 及它们所引用的模块 ( 比如 malloc.obj 、 free.obj 等 ) 自动加入到 E 中，并更新 U 和 D 以反应这个变化。事实上，标准库各目标模块里的未解析符号都可以在库内其它模块中找到定义，因此当链接器处理完 libc.lib 时， U 一定是空的。最后处理 libcd.lib ，因为此时 U 已经为空，所以链接器会抛弃它里面的所有目标模块从而结束扫描，然后合并 E 中的目标模块并输出可执行文件。

 

    上文描述了虽然各目标模块指定了不同版本的缺省标准库但仍然链接成功的例子，接下来你将目睹因为这种不严谨而导致的悲惨失败。

 

    修改 mylib.c 成这个样子 :

 

#include <crtdbg.h>

 

void foo()

{

// just a test , don't care memory leak

 

  _malloc_dbg( 1, _NORMAL_BLOCK, __FILE__, __LINE__ );

}

 

其中 _malloc_dbg 不是 ANSI C 的标准库函数，它是 VC 标准库提供的 malloc 的调试版，与相关函数配套能帮助开发者抓各种内存错误。使用它一定要定义 _DEBUG 宏，否则预处理器会把它自动转为 malloc 。继续用

 

cl /c /MLd mylib.c

 

lib /OUT:my.lib mylib.obj

 

编译打包。当再次用

 

link main.obj my.lib

 

进行链接时，我们看到了什么？天哪，一堆的 LNK2005 加上个贵为 "fatal error" 的 LNK1169 垫底，当然还少不了那个 LNK4098 。链接器是不是疯了？不，你冤枉可怜的链接器了，我拍胸脯保证它可是一直在尽心尽责地照章办事。

 

输出信息：

 

C:\>link main.obj my.lib

 

Microsoft (R) Incremental Linker Version6.00.8168

 

Copyright (C) Microsoft Corp 1992-1998. Allrights reserved.

 

 

 

LIBCD.lib(dbgheap.obj) : error LNK2005:_malloc already defined in LIBC.lib(mall

 

oc.obj)

 

LIBCD.lib(dbgheap.obj) : error LNK2005:__nh_malloc already defined in LIBC.lib(

 

malloc.obj)

 

LIBCD.lib(dbgheap.obj) : error LNK2005:__heap_alloc already defined in LIBC.lib

 

(malloc.obj)

 

LIBCD.lib(dbgheap.obj) : error LNK2005:_free already defined in LIBC.lib(free.o

 

bj)

 

LIBCD.lib(sbheap.obj) : error LNK2005:__get_sbh_threshold already defined in LI

 

BC.lib(sbheap.obj)

 

LIBCD.lib(sbheap.obj) : error LNK2005:__set_sbh_threshold already defined in LI

 

BC.lib(sbheap.obj)

 

LIBCD.lib(sbheap.obj) : error LNK2005:___sbh_heap_init already defined in LIBC.

 

lib(sbheap.obj)

 

LIBCD.lib(sbheap.obj) : error LNK2005:___sbh_find_block already defined in LIBC

 

.lib(sbheap.obj)

 

LIBCD.lib(sbheap.obj) : error LNK2005:___sbh_free_block already defined in LIBC

 

.lib(sbheap.obj)

 

LIBCD.lib(sbheap.obj) : error LNK2005:___sbh_alloc_block already defined in LIB

 

C.lib(sbheap.obj)

 

LIBCD.lib(sbheap.obj) : error LNK2005:___sbh_alloc_new_region already defined i

 

n LIBC.lib(sbheap.obj)

 

LIBCD.lib(sbheap.obj) : error LNK2005:___sbh_alloc_new_group already defined in

 

LIBC.lib(sbheap.obj)

 

LIBCD.lib(sbheap.obj) : error LNK2005:___sbh_resize_block already defined in LI

 

BC.lib(sbheap.obj)

 

LIBCD.lib(sbheap.obj) : error LNK2005:___sbh_heapmin already defined in LIBC.li

 

b(sbheap.obj)

 

LIBCD.lib(sbheap.obj) : error LNK2005:___sbh_heap_check already defined in LIBC

 

.lib(sbheap.obj)

 

LIBCD.lib(sbheap.obj) : error LNK2005:___sbh_threshold already defined in LIBC.

 

lib(sbheap.obj)

 

LINK : warning LNK4098: defaultlib"LIBCD" conflicts with use of other libs; use

 

/NODEFAULTLIB:library

 

main.exe : fatal error LNK1169: one or moremultiply defined symbols found

 

 

 

    一开始 E 、 U 、 D 为空，链接器扫描 main.obj ，把它加入 E ，把 foo 加入 U ，把 main 加入 D ，把 libc.lib 加入到当前输入文件列表的末尾。接着扫描 my.lib ， foo 从 U 转移到 D ， _malloc_dbg 加入到 U ， libcd.lib 加到当前输入文件列表的尾部。然后扫描 libc.lib ，这时会发现 libc.lib 里任何一个目标模块都没有定义 _malloc_dbg( 它只在调试版的标准库中存在 ) ，所以不会有任何一个模块因为 _malloc_dbg 而加入 E ，但是每个程序都要用到的初始化模块 ( 如 crt0.obj 等 ) 及它们所引用的模块 ( 比如 malloc.obj 、 free.obj 等 ) 还是会自动加入到 E 中，同时 U 和 D 被更新以反应这个变化。当链接器处理完 libc.lib 时， U 只剩 _malloc_dbg 这一个符号。最后处理 libcd.lib ，发现 dbgheap.obj 定义了 _malloc_dbg ，于是 dbgheap.obj 加入到 E ，它里头的未解析符号加入 U ，它定义的所有其它符号也加入 D ，这时灾难便来了。之前 malloc 等符号已经在 D 中 ( 随着 libc.lib 里的 malloc.obj 加入 E 而加入的 ) ，而 dbgheap.obj 又定义了包括 malloc 在内的许多同名符号，这引发了重定义冲突，链接器只好中断工作并报告错误。

 

     现在我们该知道，链接器完全没有责任，责任在我们自己的身上。是我们粗心地把缺省标准库版本不一致的目标文件 (main.obj) 与程序库 (my.lib) 链接起来，导致了大灾难。解决办法很简单，要么用 /MLd 选项来重编译 main.c ；要么用 /ML 选项重编译 mylib.c 。

 

在上述例子中，我们拥有库 my.lib 的源代码 (mylib.c) ，所以可以用不同的选项重新编译这些源代码并再次打包。可如果使用的是第三方的库，它并没有提供源代码，那么我们就只有改变自己程序的编译选项来适应这些库了。但是如何知道库中目标模块指定的默认库呢？其实 VC 提供的一个小工具便可以完成任务，这就是 dumpbin.exe 。运行下面这个命令

 

dumpbin /DIRECTIVES my.lib

 

输出信息：

 

C:\>dumpbin /DIRECTIVES my.lib

 

Microsoft (R) COFF Binary File DumperVersion 6.00.8168

 

Copyright (C) Microsoft Corp 1992-1998. Allrights reserved.

 

Dump of file my.lib  

 

File Type: LIBRARY

 

  Linker Directives

 

  -----------------

 

  -defaultlib:LIBCD

 

   -defaultlib:OLDNAMES

 

Summary

 

          8 .data

 

         27 .drectve

 

         18 .text

 

然后在输出中找那些 "Linker Directives" 引导的信息，你一定会发现每一处这样的信息都会包含若干个类似 "-defaultlib:XXXX" 这样的字符串，其中 XXXX 便代表目标模块指定的缺省库名。

 

知道了第三方库指定的默认标准库，再用合适的选项编译我们的应用程序，就可以避免 LNK2005 和 LNK1169 链接错误。喜欢 IDE 的朋友，你一样可以到 "Project 属性 " -> "C/C++" -> "代码生成 (codegeneration)" -> " 运行时库 (run-time library)" 项下设置应用程序的默认标准库版本，这与命令行选项的效果是一样的。