alreadydefinedin.obj-符号已定义问题原理及其解决方法.doc
《alreadydefinedin.obj-符号已定义问题原理及其解决方法.doc》由会员分享,可在线阅读,更多相关《alreadydefinedin.obj-符号已定义问题原理及其解决方法.doc(26页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、already defined in *.obj“符号已定义符号已定义”问题原理及解决方问题原理及解决方案案VC6 如果想在 stdafx.h 中定义全局变量,由于该头文件会被 include 多次,所以,经常会出现以下经典的错误:already defined in StdAfx.obj。解决方法:把该变量的定义 int g_flag 放到 stdafx.cpp 中,然后在使用的地方 extern 一下。假如你在 CAADlg.cpp 中使用了该变量 g_flag,那么就在 CAADlg.cpp 的首部,构造函数的定义之外,添加上 extern int g_flag;许多 Visual C+
2、的使用者都碰到过 LNK2005:symbol already defined 和 LNK1169:one or more multiply defined symbols found 这样的链接错误,而且通常是在使用第三方库时遇到的。对于这个问题,有的朋友可能不知其然,而有的朋友可能知其然却不知其所以然,那么本文就试图为大家彻底解开关于它的种种疑惑。 大家都知道,从 C/C+源程序到可执行文件要经历两个阶段:(1)编译器将源文件编译成汇编代码,然后由汇编器(assembler)翻译成机器指令(再加上其它相关信息)后输出到一个个目标文件(object file,VC 的编译器编译出的目标文件默
3、认的后缀名是.obj)中;(2)链接器(linker)将一个个的目标文件(或许还会有若干程序库)链接在一起生成一个完整的可执行文件。编译器编译源文件时会把源文件的全局符号(global symbol)分成强(strong)和弱(weak)两类传给汇编器,而随后汇编器则将强弱信息编码并保存在目标文件的符号表中。那么何谓强弱呢?编译器认为函数与初始化了的全局变量都是强符号,而未初始化的全局变量则成了弱符号。比如有这么个源文件:extern int errorno;int buf2 = 1,2;int *p;int main()return 0;其中 main、buf 是强符号,p 是弱符号,而 e
4、rrorno 则非强非弱,因为它只是个外部变量的使用声明。有了强弱符号的概念,链接器(Unix 平台)就会按如下规则(参考1,p549p550)处理与选择被多次定义的全局符号:规则 1: 不允许强符号被多次定义(即不同的目标文件中不能有同名的强符号);规则 2: 如果一个符号在某个目标文件中是强符号,在其它文件中都是弱符号,那么选择强符号;规则 3: 如果一个符号在所有目标文件中都是弱符号,那么选择其中任意一个;虽然上述 3 条针对的是 Unix 平台的链接器,但据作者试验,至少 VC6.0的 linker 也遵守这些规则。由此可知多个目标文件不能重复定义同名的函数与初始化了的全局变量,否则必
5、然导致 LNK2005 和 LNK1169 两种链接错误。可是,有的时候我们并没有在自己的程序中发现这样的重定义现象,却也遇到了此种链接错误,这又是何解?嗯,问题稍微有点儿复杂,容我慢慢道来。众所周知,ANSI C/C+ 定义了相当多的标准函数,而它们又分布在许多不同的目标文件中,如果直接以目标文件的形式提供给程序员使用的话,就需要他们确切地知道哪个函数存在于哪个目标文件中,并且在链接时显式地指定目标文件名才能成功地生成可执行文件,显然这是一个巨大的负担。所以 C 语言提供了一种将多个目标文件打包成一个文件的机制,这就是静态程序库(static library)。开发者在链接时只需指定程序库的
6、文件名,链接器就会自动到程序库中寻找那些应用程序确实用到的目标模块,并把(且只把)它们从库中拷贝出来参与构建可执行文件。几乎所有的 C/C+开发系统都会把标准函数打包成标准库提供给开发者使用(有不这么做的吗?)。程序库为开发者带来了方便,但同时也是某些混乱的根源。我们来看看链接器(Unix 平台)是如何解析(resolve)对程序库的引用的(参考1,p556)。在符号解析(symbol resolution)阶段,链接器按照所有目标文件和库文件出现在命令行中的顺序从左至右依次扫描它们,在此期间它要维护若干个集合:(1)集合 E 是将被合并到一起组成可执行文件的所有目标文件集合;(2)集合 D
7、是所有之前已被加入 E 的目标文件定义的符号集合;(3)集合 U 是未解析符号(unresolved symbols,即那些被 E 中目标文件引用过但在 D 中还不存在的符号)的集合。一开始,E、D、U 都是空的。(1): 对命令行中的每一个输入文件 f,链接器确定它是目标文件还是库文件,如果它是目标文件,就把 f 加入到 E,并把 f 中未解析的符号和已定义的符号分别加入到 U、D 集合中,然后处理下一个输入文件。(2): 如果 f 是一个库文件,链接器会尝试把 U 中的所有未解析符号与 f 中各目标模块定义的符号进行匹配。如果某个目标模块 m 定义了一个 U 中的未解析符号,那么就把 m
8、加入到 E 中,并把 m 中未解析的符号和已定义的符号分别加入到 U、D 集合中。不断地对 f 中的所有目标模块重复这个过程直至到达一个不动点(fixed point),此时 U 和 D 不再变化。而那些未加入到E 中的 f 里的目标模块就被简单地丢弃,链接器继续处理下一输入文件。(3): 当扫描完所有输入文件时如果 U 非空或者有同名的符号被多次加入D,链接器报告错误信息并退出。否则,它把 E 中的所有目标文件合并在一起生成可执行文件。上述规则针对的是 Unix 平台链接器,而 VC(至少 VC6.0)linker 则有相当的不同: 它首先依次处理命令行中出现的所有目标文件,然后依照顺序不停
9、地扫描所有的库文件,直至 U 为空或者某遍(从头到尾依次把所有的库文件扫描完称为一遍)扫描过程中 U、D 无任何变化时结束扫描,此刻再根据 U是否为空以及是否有同名符号重复加入 D 来决定是出错退出还是生成可执行文件。很明显 Unix 链接器对输入文件在命令行中出现的顺序十分敏感,而 VC 的算法则可最大限度地减少文件顺序对链接的影响。作者不清楚Unix 下新的开发工具是否已经改进了相应的做法,欢迎有实践经验的朋友补充这方面的信息(补充于 2005 年 10 月 10 日: 经试验,使用 gcc 3.2.3 的MinGW 3.1.0 的链接器表现与参考1描述的一致)。VC 带的编译器是 cl.
10、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.
11、lib),/MTd 对应调试版多线程静态标准库(libcmtd.lib),/MDd 对应调试版多线程 DLL 标准库(导入库msvcrtd.lib,DLL 是 msvcrtd.dll)。虽然我们的确在编译时明白无误地告诉了编译器应用程序希望使用什么版本的标准库,可是当编译器干完了活,轮到链接器开工时它又如何得知一个个目标文件到底在思念谁?为了传递相思,我们的编译器就干了点秘密的勾当。在 cl 编译出的目标文件中会有一个专门的区域(关心这个区域到底在文件中什么地方的朋友可以参考 COFF 和 PE文件格式)存放一些指导链接器如何工作的信息,其中有一项就叫缺省库(default library),
12、它指定了若干个库文件名,当链接器扫描该目标文件时将按照它们在目标模块中出现的顺序处理这些库名: 如果该库在当前输入文件列表中还不存在,那么便把它加入到输入文件列表末尾,否则略过。说到这里,我们先来做个小实验。写个顶顶简单的程序,然后保存为 main.c :/* main.c */int main() return 0; 用下面这个命令编译 main.c(什么?你从不用命令行来编译程序?这个.) :cl /c main.c/c 是告诉 cl 只编译源文件,不用链接。因为/ML 是缺省选项,所以上述命令也相当于: cl /c /ML main.c 。如果没什么问题的话(要出了问题才是活见鬼!当然除
13、非你的环境变量没有设置好,这时你应该去 VC 的 bin 目录下找到 vcvars32.bat 文件然后运行它。),当前目录下会出现一个 main.obj 文件,这就是我们可爱的目标文件。随便用一个文本编辑器打开它(是的,文本编辑器,大胆地去做别害怕),搜索“defaultlib“字符串,通常你就会看到这样的东西: “-defaultlib:LIBC -defaultlib:OLDNAMES“。啊哈,没错,这就是保存在目标文件中的缺省库信息。我们的目标文件显然指定了两个缺省库,一个是单线程静态版标准库 libc.lib(这与/ML 选项相符);一个是oldnames.lib(它是为了兼容微软以
14、前的 C/C+开发系统,基本不用了,为了简化讨论可以忽略它)。另外,如果在源程序中用了/* xxxx 代表实际的库文件名 */#pragma comment(lib,“xxxx“)编译指示命令(compiler directive)指定要链接的库,那么这个信息也会被保存到目标文件的缺省库信息项中,且位于缺省标准库之前。如果有多个这样的命令,那么对应库名在目标文件中出现的顺序与它们在源程序中出现的顺序完全一致(且都在缺省标准库之前)。VC 的链接器是 link.exe,因为 main.obj 保存了缺省库信息,所以可以用link main.obj libc.lib或者link main.obj来
15、生成可执行文件 main.exe,这两个命令是等价的。但是如果你用link main.obj libcd.lib的话,链接器会给出一个警告: “warning LNK4098: defaultlib “LIBC“ conflicts with use of other libs; use /NODEFAULTLIB:library“,因为你显式指定的标准库版本与目标文件的缺省值不一致。通常来说,应该保证链接器合并的所有目标文件指定的缺省标准库版本一致,否则编译器一定会给出上面的警告,而 LNK2005 和 LNK1169 链接错误则有时会出现有时不会。那么这个有时到底是什么时候?呵呵,别着急,
16、下面的一切正是为喜欢追根究底的你准备的。建一个源文件,就叫 mylib.c,内容如下:/* mylib.c */#include void foo(void)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(
17、void);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“。我们根据前文所述的扫描规则来分析一下链接器此时做了些啥(加一个/VERBOSE 选项就可以看到详尽的链接过程,但要注意,几乎所有
18、的 C 编译器都会在符号前加一个下划线后再输出,所以在目标文件和链接输出信息中看到的符号名都比在源程序中见到的多出一个_,此点不可不察。)。一开始 E、U、D 都是空集。链接器首先扫描 main.obj,把它的默认标准库 libc.lib 加入到输入文件列表末尾,它自己加入 E 集合,同时未解析的foo 加入 U,main 加入 D。接着扫描 my.lib,因为这是个库,所以会拿当前 U 中的所有符号(当然现在就一个 foo)与 my.lib 中的所有目标模块(当然也只有一个 mylib.obj)依次匹配,看是否有模块定义了 U 中的符号。结果mylib.obj 确实定义了 foo,于是它加入
19、到 E,foo 从 U 转移到 D,未解析的 printf 加入到 U,指定的默认标准库 libcd.lib 也加到输入文件列表末尾(在 libc.lib 之后)。不断地在 my.lib 库的各模块上进行迭代以匹配 U 中的符号,直到 U、D 都不再变化。很明显,现在就已经到达了这么一个不动点,所以接着扫描下一个输入文件,就是 libc.lib。链接器发现 libc.lib 里的printf.obj 里定义有 printf,于是 printf 从 U 移到 D,printf.obj 加入到E,它定义的所有符号加入到 D,它里头的未解析符号加入到 U。如果链接时没有指定/ENTRY(程序入口点选
20、项),那么链接器默认的入口点就是函数mainCRTStartup(GUI 程序的默认入口点则是 WinMainCRTStartup),它在 crt0.obj 中被定义,所以 crt0.obj 及它直接或间接引用的模块(比如malloc.obj、free.obj 等)都被加入到 E 中,这些目标模块指定的默认库(只crt0init.obj 指定了 kernel32.lib)加到输入文件列表末尾,同时更新 U 和D。不断匹配 libc.lib 中各模块直至到达不动点,然后处理 libcd.lib,但是它里面的所有目标模块都没有定义 U 中的任何一个符号,所以链接器略过它进入到最后一个输入文件 ke
21、rnel32.lib。事实上,U 中已有和将要加入的未解析符号都可以在其中找到定义,那么当处理完 kernel32.lib 时,U 必然为空,于是链接器合并 E 中的所有模块生成可执行文件。上文描述了虽然各目标模块指定了不同版本的缺省标准库但仍然链接成功的例子,接下来你将目睹因为这种不严谨而导致的悲惨失败。修改 mylib.c 成这个样子:#include void foo(void)/ just a test , dont care memory leak_malloc_dbg( 1, _NORMAL_BLOCK, _FILE_, _LINE_ );其中_malloc_dbg 不是 ANSI
22、 C 的标准库函数,它是 VC 标准库提供的malloc 的调试版,与相关函数配套能帮助开发者抓各种内存错误。使用它一定要定义_DEBUG 宏,否则预处理器会把它自动转为 malloc。继续用cl /c /MLd mylib.clib /OUT:my.lib mylib.obj编译打包。当再次用link main.obj my.lib进行链接时,我们看到了什么?天哪,一堆的 LNK2005 加上个贵为“fatal error“的 LNK1169 垫底,当然还少不了那个 LNK4098。链接器是不是疯了?不,你冤枉可怜的链接器了,我拍胸脯保证它可是一直在尽心尽责地照章办事。一开始 E、U、D 为
23、空,链接器扫描 main.obj,把 libc.lib 加到输入文件列表末尾,把 main.obj 加进 E,把 foo 加进 U,把 main 加进 D。接着扫描 my.lib,于是 mylib.obj 加入 E,libcd.lib 加到输入文件列表末尾,foo从 U 转移到 D,_malloc_dbg 加进 U。然后扫描 libc.lib,这时会发现libc.lib 里任何一个目标模块都没有定义_malloc_dbg(它只在调试版的标准库中存在),所以不会有任何一个模块因为_malloc_dbg 而加入 E。但因为libc.lib 中的 crt0.obj 定义了默认入口点函数 mainCR
24、TStartup,所以crt0.obj 及它直接或间接引用的模块(比如 malloc.obj、free.obj 等)都被加入到 E 中,这些目标模块指定的默认库(只 crt0init.obj 指定了 kernel32.lib)加到输入文件列表末尾,同时更新 U 和 D。不断匹配 libc.lib 中各模块直至到达不动点后再处理 libcd.lib,发现 dbgheap.obj 定义了_malloc_dbg,于是 dbgheap.obj 加入到 E,它的未解析符号加入 U,它定义的所有其它符号加入 D,这时灾难便来了。之前 malloc 等符号已经在 D 中(随着libc.lib 里的 mall
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- alreadydefinedin obj 符号 定义 问题 原理 及其 解决方法
限制150内