链接器如何使用静态库来解析引用

在符号解析(symbol resolution)阶段，链接器按照所有目标文件和库文件出现在命令行中的顺序从左至右依次扫描它们，在此期间它要维护若干个集合:(1)集合E是将被合并到一起组成可执行文件的所有目标文件集合；(2)集合D是所有之前已被加入E的目标文件定义的符号集合；(3)集合U是未解析符号(unresolved symbols，即那些被E中目标文件引用过但在D中还不存在的符号)的集合。一开始，E、D、U都是空的。
(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): 当扫描完所有输入文件时如果U非空或者有同名的符号被多次加入D，链接器报告错误信息并退出。否则，它把E中的所有目标文件合并在一起生成可执行文件。
     上述规则针对的是Unix平台链接器，而VC(至少VC6.0)linker则有相当的不同: 它首先依次处理命令行中出现的所有目标文件，然后依照顺序不停地扫描所有的库文件，直至U为空或者某遍(从头到尾依次把所有的库文件扫描完称为一遍)扫描过程中U、D无任何变化时结束扫描，此刻再根据U是否为空以及是否有同名符号重复加入D来决定是出错退出还是生成可执行文件。很明显Unix链接器对输入文件在命令行中出现的顺序十分敏感，而VC的算法则可最大限度地减少文件顺序对链接的影响。
     如果在命令行中，定义一个符号的库出现在引用这个符号的目标文件之前，那么引用就不能被解析，链接会失败。关于库的一般准则是将它们放在命令行的结尾。如果各个库的成员是相互独立的－也就是说没有成员引用另一个成员定义的符号－那么这些库就可以以任何顺序放置在命令行的结尾处。如果库不是独立的，那么它们必须排序。如果需要满足依赖需求，可以在命令行上重复库，也可以将多个库合并成一个单独的库。