编译器Linker工作原理.docx

  编译器Linker工作原理 收藏 转自： LNK2005“符号已定义”错误及Linker工作原理2006-10-24 17:44许多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)两类传给汇编器，而随后汇编器则将强弱信息编码并保存在目标文件的符号表中。

那么何谓强弱呢？编译器认为函数与初始化了的全局变量都是强符号，而未初始化的全局变量则成了弱符号比如有这么个源文件: 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 use of other libs; use /NODEFAULTLIB:library"，因为你显式指定的标准库版本与目标文件的缺省值不一致。

通常来说，应该保证链接器合并的所有目标文件指定的缺省标准库版本一致，否则编译器一定会给出上面的警告，而LNK2005和LNK1169链接错误则有时会出现有时不会那么这个有时到底是什么时候？呵呵，别着急，下面的一切正是为喜欢追根究底的你准备的     建一个源文件，就叫mylib.c，内容如下: /* mylib.c */ #include void foo(){   printf("%s","I am from mylib!\n");} 用 cl /c /MLd mylib.c 命令编译，注意/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链接错误，你仅仅是得到了一条警告信息:"warning LNK4098: 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中的目标模。