vc link 2005错误

第一篇：
连接器都干了些什么？

（http://www.cppblog.com/jacky2019/archive/2007/03/29/20891.html）
Posted on 2007-03-29 19:10 小熊

目前项目在不停的增加，我想仍是在它规模仍旧很小的时候把它的模块分清楚，不一样模块分到不一样的 projects 里面，这里面出现了不少问题，也反映了我知识上的不少不足。

1 ， project 最后的输出要设置清楚，有的是 static lib ，有的是 dll ，有的是 exe ，不同的输出要设置好，它们都是 linker 的成果，可是以不一样的方式应用。

2 ， project dependency 设置好， build order 什么的，经过这些把一系列的 project 联系起来。

3 ， project 之间的联系就经过之间的 lib ， dll 来联系，这时候就涉及到 linker 的工做了。

 

许多 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 <stdio.h>

void foo()

{

   printf("%s","I am from mylib!\n");

}

用

cl /c /MLd mylib.c

（ ML 要是大写的，不然不认。）

命令编译，注意 /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 中的目标模块并输出可执行文件。

    上文描述了虽然各目标模块指定了不一样版本的缺省标准库但仍然连接成功的例子，接下来你将目击由于这种不严谨而致使的悲惨失败。

    修改 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)" 项下设置应用程序的默认标准库版本，这与命令行选项的效果是同样的。

这是一片很是好的文章，若是你看到了这里的话，那我只能恭喜你成功了！

Have  fun ！



第二篇：
LNK2005 xxx already defined in libc.lib

（http://hi.baidu.com/yuanqizhu/blog/item/026f187bd7f25df10bd1879e.html）
2008-04-23 22:05  缘起助


今晚在VC6.0下编程时遇到下面这种错误：

源程序在没有修改的状况下，debug一切正常，在link release时报错：
Linking...
LINK : warning LNK4075: ignoring /EDITANDCONTINUE due to /INCREMENTAL:NO specification
libcd.lib(dbgheap.obj) : error LNK2005: _malloc already defined in libc.lib(malloc.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: _calloc already defined in libc.lib(calloc.obj)
libcd.lib(dbgheap.obj) : error LNK2005: _realloc already defined in libc.lib(realloc.obj)
libcd.lib(dbgheap.obj) : error LNK2005: _free already defined in libc.lib(free.obj)
libcd.lib(dbgheap.obj) : error LNK2005: __msize already defined in libc.lib(msize.obj)
libcd.lib(sbheap.obj) : error LNK2005: __get_sbh_threshold already defined in libc.lib(sbheap.obj)
libcd.lib(sbheap.obj) : error LNK2005: __set_sbh_threshold already defined in libc.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 libc.lib(sbheap.obj)
libcd.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_region already defined in 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 libc.lib(sbheap.obj)
libcd.lib(sbheap.obj) : error LNK2005: ___sbh_heapmin already defined in libc.lib(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)
libc.lib(crt0init.obj) : warning LNK4098: defaultlib "libcd.lib" conflicts with use of other libs; use /NODEFAULTLIB:library
Release/zfd.exe : fatal error LNK1169: one or more multiply defined symbols found
Error executing link.exe.

一看就是链接错误，libcd和libc冲突，查了下msdn，找到了办法。
错误消息

默认库“library”与其余库的使用冲突；请使用 /NODEFAULTLIB:library
您试图与不兼容的库连接。
注意
运 行时库如今包含可防止混合不一样类型的指令。若是试图在同一个程序中使用不一样类型的运行时库或使用调试和非调试版本的运行时库，则将收到此警告。例如，若是 编译一个文件以使用一种运行时库，而编译另外一个文件以使用另外一种运行时库（例如单线程运行时库对多线程运行时库），并试图连接它们，则将获得此警告。应将 全部源文件编译为使用同一个运行时库。有关更多信息，请参见使用运行时库（/MD、/MT 和 /LD）编译器选项。
可使用连接器的 /VERBOSE:LIB 开关来肯定连接器搜索的库。若是收到 LNK4098，并想建立使用如单线程、非调试运行时库的可执行文件，请使用 /VERBOSE:LIB 选项肯定连接器搜索的库。连接器做为搜索的库输出的应是 LIBC.lib，而非 LIBCMT.lib、MSVCRT.lib、LIBCD.lib、LIBCMTD.lib 和 MSVCRTD.lib。对每一个要忽略的库可使用 /NODEFAULTLIB，以通知连接器忽略错误的运行时库。
下表显示根据要使用的运行时库应忽略的库。
若要使用此运行时库    请忽略这些库
单线程 (libc.lib)
libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
多线程 (libcmt.lib)
libc.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
使用 DLL 的多线程 (msvcrt.lib)
libc.lib、libcmt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
调试单线程 (libcd.lib)
libc.lib、libcmt.lib、msvcrt.lib、libcmtd.lib、msvcrtd.lib
调试多线程 (libcmtd.lib)
libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、msvcrtd.lib
使用 DLL 的调试多线程 (msvcrtd.lib)
libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib

最后使用/nodefaultlib:"libcd.lib" 命令连接成功。