C++程序从编译到链接然后再到调用的整个过程如下。
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 中的目标模块并输出可执行文件。 上文描述了虽然各目标模块指定了不同版本的缺省标准库但仍然链接成功的例子,接下来你将目睹因为这种不严谨而导致的悲惨失败。 修改 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 Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights 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 more multiply 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 Dumper Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights 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++" -> " 代码生成 (code generation)" -> " 运行时库 (run-time library)" 项下设置应用程序的默认标准库版本,这与命令行选项的效果是一样的。 |
从编译到链接
最新推荐文章于 2023-01-17 15:10:44 发布
从编译到链接
2010-11-06 18:24