【转】C,C++编译，链接过程详解

在网上找到的，不知道是哪位大神写的，贴出来共大家参考！

一、       前言

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

 

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

 

二、       理解几个概念

首先要知道一些概念： 
编译：编译器对源代码进行编译，是将以文本形式存在的源代码翻译为机器语言形式的目标文件的过程。 
编译单元：对于C++来说，每一个cpp文件就是一个编译单元。从之前的编译过程的演示可以看出，各个编译单元之间是互相不可知的。 
目标文件：由编译所生成的文件，以机器码的形式包含了编译单元里所有的代码和数据，以及一些其他的信息。 

 

三、       C++编译过程

C++程序从编译到链接再到调用的整个过程是这样的：

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

编译时会经历以下过程：

1．  首先经历的是预处理过程：将头文件加载进来，并且将各种#define信息代入，生成一个个独力的编译单元。

经历编译预处理过程之后会生成以cpp文件为基础的编译单元，在每个编译单元中，源码中#include的位置将被include的头文件内容替换掉，因此在以后的编程中需要严格注意include的先后顺序。因为C++语言是一种很注重申明的语言，为什么会这样，这与程序的编译过程和链接过程的算法有关。

2．  在编译单元生成之后，便是将编译单元进行编译，生成目标文件（*.obj文件）

对于主流的编译过程，通常存在两个阶段：首先是生成汇编语言，然后使用汇编器生成机器语言。机器语言顾名思义就是0101这样的二进制代码。

例如以下代码（这里写的是Intel 80x86的汇编代码，每一种不同架构的芯片的汇编语言是不同的。）:

MOV AX，BX

生成机器语言的过程就是将MOV和AX和BX原封不动的用0101替换掉，如MOV代码是35，AX为01，BX为10，则翻译出来的机器码就是350110，二进制也就是001101010000000100010000。

3．  接下来的任务是链接，生成可执行文件。

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

 

四、       链接器的使用

许多Visual C++ 的使用者在编译源码时都碰到过以下链接错误(通常是在使用第三方库时遇到的)：

LNK2005:symbol already defined

LNK1169:one or more multiply defined symbols found

对于这个问题，有的朋友可能不知其然，而有的朋友可能知其然却不知其所以然，那么本文就试图为大家彻底解开关于它的种种疑惑。

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

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

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

 

编译器在编译源文件的时候会把源文件的全局符号 (global symbol) 分成强 (strong) 和弱 (weak) 两类传给汇编器，而随后汇编器则将强弱信息编码并保存在目标文件的符号表中。

那么何谓强弱呢？编译器认为函数与初始化了的全局变量都是强符号，而未初始化的全局变量则成了弱符号。

比如以下源文件 :

externint errorno;

intbuf[2] = {1,2};

int *p;

intmain()

{return 0; }

其中 main 、buf 是强符号， p 是弱符号，而 errorno 则非强非弱，因为它只是个外部变量的使用声明（编译时不产生内存分配）。

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

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

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

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

由上可知多个目标文件不能重复定义同名的函数与初始化了的全局变量，否则必然导致 LNK2005 和 LNK1169 两种链接错误。

可是，有的时候我们并没有在自己的程序中发现这样的重定义现象，却也遇到了此种链接错误，这又是何解？嗯，问题稍微有点儿复杂，容我慢慢道来。

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

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

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

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

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

(3) 集合 D 是所有之前已被加入到 E 的目标文件定义的符号集合。

 

一开始，这三个集合都是空的。 链接器的工作过程：

(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*/

intmain() { return 0; }

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

cl /cmain.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 保存了缺省库信息，所以可以用以下命令来生成可执行文件main.exe：

linkmain.obj libc.lib

或者

linkmain.obj

这两个命令是等价的。

 

但是如果你用以下命令：

linkmain.obj libcd.lib

链接器会给出一个警告 :

"warning LNK4098: defaultlib "LIBC"conflicts with use of other libs; use /NODEFAULTLIB:library" ，

因为你显式指定的标准库版本与目标文件的缺省值不一致。

通常来说，应该保证链接器合并的所有目标文件与指定的缺省标准库版本保持一致，否则编译器一定会给出上面的警告，而 LNK2005 和 LNK1169 链接错误则有时会出现有时不会。

那么这个有时到底是什么时候？呵呵，别着急，下面的一切正是为喜欢追根究底的你准备的。

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

/*mylib.c */

#includevoid foo() { printf("%s","I am from mylib!\n"); }

用 以下命令编译（ML是大小写敏感的。）：

cl /c/MLd mylib.c

注意 /MLd 选项是指定 libcd.lib 为默认标准库。

lib.exe是 VC 自带的用于将目标文件打包成程序库的命令，所以我们可以用以下命令将 mylib.obj 打包成库：

lib/OUT:my.lib mylib.obj

输出的库文件名是 my.lib 。

接下来把 main.c 改成 :

/*main.c */

voidfoo();

intmain() { foo(); return 0; }

用 以下命令编译：

cl /cmain.c

然后用 以下命令链接：

linkmain.obj my.lib

这个命令能够成功地生成 main.exe 而不会产生 LNK2005 和 LNK1169 链接错误，你仅仅是得到了一条警告信息 :

"warning LNK4098: defaultlib "LIBCD"conflicts with use of other libs; use /NODEFAULTLIB:library" 。

我们根据前文所述的扫描规则来分析一下链接器此时做了些啥。

（1）一开始 E 、 U 、 D 都是空集，

输入文件列表中存放两个文件：main.obj/my.lib

（2）链接器首先在命令行中扫描到 main.obj ，把它加入 E 集合，同时把未解析的 foo 加入 U ，把 main 加入 D ，而且因为 main.obj 的默认标准库是 libc.lib ，所以它被加入到当前输入文件列表的末尾。

此时三个集合中的内容分别为（编译出的名字可能与下面列出的名字不同）：

E（目标文件集合）：main.obj

U（未解析符号集合，弱符号）：foo

D（已定义符合集合，强符号）：main

输入文件列表中内容为：main.obj/my.lib/libc.lib

（3）接着扫描到 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 的后面 ) 。

此时三个集合中的内容分别为（编译出的名字可能与下面列出的名字不同）：

E（目标文件集合）：main.obj/mylib.obj

U（未解析符号集合，弱符号）：printf

D（已定义符合集合，强符号）：main/ foo

输入文件列表中内容为：main.obj/my.lib/libc.lib/libcd.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 voidfoo()

{ // 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.clib /OUT:my.lib mylib.obj

当再次用以下命令进行链接时：

link main.objmy.lib

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

C:\>link main.obj my.lib Microsoft (R)Incremental Linker Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998.All rights reserved. LIBCD.lib(dbgheap.obj) : error LNK2005: _malloc alreadydefined 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 inLIBC.lib(free.o bj) LIBCD.lib(sbheap.obj) : error LNK2005: __get_sbh_thresholdalready 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 inLIBC. lib(sbheap.obj) LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_find_blockalready 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 inLIB 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 definedin LIBC.lib(sbheap.obj) LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_resize_blockalready 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 inLIBC. lib(sbheap.obj) LINK : warning LNK4098: defaultlib "LIBCD"conflicts with use of other libs; use /NODEFAULTLIB:library main.exe : fatalerror LNK1169: one or more multiply defined symbols found

连接器的工作过程如下：

（1）一开始 E 、 U 、 D 为空

（2）链接器扫描 main.obj ，把它加入 E ，把 foo 加入 U ，把 main 加入 D ，把libc.lib 加入到当前输入文件列表的末尾。

（3）接着扫描 my.lib ， foo 从 U 转移到 D ， _malloc_dbg 加入到 U ，libcd.lib 加到当前输入文件列表的尾部。

（4）然后扫描 libc.lib ，这时会发现 libc.lib 里任何一个目标模块都没有定义 _malloc_dbg( 它只在调试版的标准库中存在 ) ，所以不会有任何一个模块因为 _malloc_dbg 而加入 E ，但是每个程序都要用到的初始化模块 ( 如 crt0.obj 等 ) 及它们所引用的模块 ( 比如 malloc.obj 、free.obj 等 ) 还是会自动加入到 E 中，同时 U 和 D 被更新以反应这个变化。

（5）当链接器处理完 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 Dumper Version 6.00.8168 Copyright (C) Microsoft Corp1992-1998. All rights reserved. Dump of file my.lib File Type: LIBRARY LinkerDirectives ----------------- -defaultlib:LIBCD -defaultlib:OLDNAMES Summary 8.data 27 .drectve 18 .text

然后在输出中找那些 "Linker Directives" 引导的信息，你一定会发现每一处这样的信息都会包含若干个类似 "-defaultlib:XXXX" 这样的字符串，其中 XXXX便代表目标模块指定的缺省库名。 知道了第三方库指定的默认标准库，再用合适的选项编译我们的应用程序，就可以避免LNK2005 和 LNK1169 链接错误。

喜欢 IDE 的朋友，你一样可以到 "Project 属性 " -> "C/C++" -> " 代码生成 (code generation)" -> " 运行时库(run-time library)" 项下设置应用程序的默认标准库版本，这与命令行选项的效果是一样的。

 

五、       参考资料：

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

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

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

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

 

以上内容欢迎大家踊跃讨论，如有错误，欢迎指正。