warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /N

LNK4098：defaultlib "×××" conflicts with use of other libs

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++开发系统，基本不用了，为了简化讨论可以忽略它)。另外，如果在源程序中用了

/* xxxx代表实际的库文件名 */
#pragma comment(lib,"xxxx")

编译指示命令(compiler directive)指定要链接的库，那么这个信息也会被保存到目标文件的缺省库信息项中，且位于缺省标准库之前。如果有多个这样的命令，那么对应库名在目标文件中出现的顺序与它们在源程序中出现的顺序完全一致(且都在缺省标准库之前)。

    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(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(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选项就可以看到详尽的链接过程，但要注意，几乎所有的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，于是它加入到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(程序入口点选项)，那么链接器默认的入口点就是函数 mainCRTStartup(GUI程序的默认入口点则是WinMainCRTStartup)，它在crt0.obj中被定义，所以crt0.obj 及它直接或间接引用的模块(比如malloc.obj、free.obj等)都被加入到E中，这些目标模块指定的默认库(只crt0init.obj指定了kernel32.lib)加到输入文件列表末尾，同时更新U和D。不断匹配libc.lib中各模块直至到达不动点，然后处理libcd.lib，但是它里面的所有目标模块都没有定义U中的任何一个符号，所以链接器略过它进入到最后一个输入文件kernel32.lib。事实上，U中已有和将要加入的未解析符号都可以在其中找到定义，那么当处理完kernel32.lib时，U必然为空，于是链接器合并E中的所有模块生成可执行文件。

    上文描述了虽然各目标模块指定了不同版本的缺省标准库但仍然链接成功的例子，接下来你将目睹因为这种不严谨而导致的悲惨失败。

    修改mylib.c成这个样子:

#include <crtdbg.h>

void foo(void)
{
   // 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。链接器是不是疯了？不，你冤枉可怜的链接器了，我拍胸脯保证它可是一直在尽心尽责地照章办事。

    一开始E、U、D为空，链接器扫描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定义了默认入口点函数mainCRTStartup，所以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里的malloc.obj加入E而加入的)，而 dbgheap.obj及因它而引入的其它模块又定义了包括malloc在内的许多同名符号，导致了重定义冲突。所以链接器在处理完所有输入文件(是的，即使中途有重定义冲突它也会处理所有的文件以便生成一个完整的冲突列表)后只好报告: 这活儿没法儿干。

    现在我们该知道，链接器完全没有责任，责任在我们自己的身上。是我们粗心地把缺省标准库版本不一致的目标文件(main.obj)与程序库 (my.lib)链接起来，引发了大灾难。解决办法很简单，要么用/MLd选项来重编译main.c；要么用/ML选项重编译mylib.c；再或者干脆在链接时用/NODEFAULTLIB:XXX选项忽略默认库XXX，但这种方法非常不保险(想想为什么？)，所以不推荐。

    在上述例子中，我们拥有库my.lib的源代码(mylib.c)，所以可以用不同的选项重新编译这些源代码并再次打包。可如果使用的是第三方的库，它并没有提供源代码，那么我们就只有改变自己程序的编译选项来适应这些库了。但是如何知道库中目标模块指定的默认库呢？其实VC提供的一个小工具便可以完成任务，这就是dumpbin.exe。运行下面这个命令

dumpbin /DIRECTIVES my.lib

然后在输出中找那些"Linker Directives"引导的信息，你一定会发现每一处这样的信息都会包含若干个类似"-defaultlib:XXXX"这样的字符串，其中XXXX便代表目标模块指定的缺省库名(注意，如果在编译时指定了/Zl选项，那么目标模块中将不会有defaultlib信息)。

    知道了第三方库指定的默认标准库，再用合适的选项编译我们的应用程序，就可以避免LNK2005和LNK1169链接错误。喜欢IDE的朋友，你一样可以到 "Project属性" -> "C/C++" -> "代码生成(code generation)" -> "运行时库(run-time library)" 项下设置应用程序的默认标准库版本，这与命令行选项的效果是一样的。

 

 

 

You are trying to link with incompatible libraries. Important   The run-time libraries now contain directives to prevent mixing different types. You’ll receive this warning if you try to use different types or debug and non-debug versions of the run-time library in the same program. For example, if you compiled one file to use one kind of run-time library and another file to use another kind (for example, single-threaded versus multithreaded) and tried to link them, you’ll get this warning. You should compile all source files to use the same run-time library.

 

总之，一句话，lib之间有冲突。需要删除导入的一些libs。

 

 

 

版　本	类　型	使用的library	被忽略的library
R Release	单线程	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
D   Debug	单线程	libcd.lib	libc.lib, libcmt.lib, msvcrt.lib, libcmtd.lib, msvcrtd.lib
	多线程	libcmtd.lib	libc.lib, libcmt.lib, msvcrt.lib, libcmtd.lib, msvcrtd.lib
	使用DLL的多线程	msvcrtd.lib	libc.lib, libcmt.lib, msvcrt.lib, libcd.lib, libcmtd.lib

 

例如编译Release版本的单线程的工程，在linker的命令行加入如下的参数：

 

/NODEFAULTLIB:libcmt.lib /NODEFAULTLIB:msvcrt.lib /NODEFAULTLIB:libcd.lib /NODEFAULTLIB:libcmtd.lib /NODEFAULTLIB:msvcrtd.lib

 

当然，通过VC6.0的开发环境也可以配置。选择Project -> Setting，出现Project Setting对话框，单击Link标签，在Category下拉菜单中选择Input，在下方的Ignore libraries: 输入框中输入“被忽略的library”框中对应的libs。输入时注意当前Build是什么版本，libs之间用“，”隔开。“Ingore all default libraries”不能勾选。

 

 

 

 

 

指定与你项目连接的运行期库
/MT多线程应用程序
/Mtd多线程应用程序(DEBUG)
/MD多线程DLL
/MDd多线程DLL(DEBUG)

 

 

 

 

 

 

 

前段时间编译一个引用自己写的静态库的程序时老是出现链接时的多个重定义的错误，而自己的代码明明没有重定义这些东西，譬如：
LIBCMT.lib(_file.obj) : error LNK2005: ___initstdio already defined in libc.lib(_file.obj)
LIBCMT.lib(_file.obj) : error LNK2005: ___endstdio already defined in libc.lib(_file.obj)
LIBCMT.lib(_file.obj) : error LNK2005: __cflush already defined in libc.lib(_file.obj)
LIBCMT.lib(_file.obj) : error LNK2005: __iob already defined in libc.lib(_file.obj)
LIBCMT.lib(osfinfo.obj) : error LNK2005: __alloc_osfhnd already defined in libc.lib(osfinfo.obj)
LIBCMT.lib(osfinfo.obj) : error LNK2005: __set_osfhnd already defined in libc.lib(osfinfo.obj)
LIBCMT.lib(osfinfo.obj) : error LNK2005: __free_osfhnd already defined in libc.lib(osfinfo.obj)
LIBCMT.lib(osfinfo.obj) : error LNK2005: __get_osfhandle already defined in libc.lib(osfinfo.obj)
LIBCMT.lib(osfinfo.obj) : error LNK2005: __open_osfhandle already defined in libc.lib(osfinfo.obj)
LIBCMT.lib(tolower.obj) : error LNK2005: __tolower already defined in libc.lib(tolower.obj)
LIBCMT.lib(tolower.obj) : error LNK2005: _tolower already defined in libc.lib(tolower.obj)
等等。

 

所 以初步估计是编译器的问题，通过网上搜索和查看msdn，原来是Visual C++ 编译器选项的关于单线程或多线程运行时例程的问题：我的那个静态库编译时/ML单线程版本的，而引用它的程序是/MT多线程版本的，他们在编译分别讲 libc.lib和LIBCMT.lib连接到各自的代码中，估计libc.lib和LIBCMT.lib只是单线程与多线程的区别，基本代码相差无几， 所以会产生链接时重定义错误；然后把编译静态库的选项/ML改成/MT就没事了。

 

要注意的是：/MD也是多线程版本的；被应用的用户链接库 要和应用者有相同的编译选项，/MD与/MT一起有时候会有错误的，有时候就没有，我试过这种情况；而/MD和/ML似乎是没有问题的；/MT和/ML是 肯定会有问题的。有没有其他情况就不清楚了，有兴趣的可以测试一下，^_^

 

如果是代码是用于多线程的，最好编译成多线程版本的，否则可能会出现一些意想不到的问题。

 

编译器选项设置（vc6）：工程 -> 设置 -> C/C++ -> 工程选项   里可以修改

 

附：

 

下面是msdn关于Visual C++ 编译器选项的说明：

 

这些选项选择单线程或多线程运行时例程，指示多线程模块是否为 DLL，并选择运行时库的发布版本或调试版本。

 

选项       说明
/MD        定义 _MT 和 _DLL 以便同时从标准 .h 文件中选择运行时例程的多线程特定版本和 DLL 特定版本。此选项还使编译器将库名 MSVCRT.lib 放入 .obj 文件中。
用此选项编译的应用程序静态链接到 MSVCRT.lib。该库提供允许链接器解析外部引用的代码层。实际工作代码包含在 MSVCR71.DLL 中，该库必须在运行时对于与 MSVCRT.lib 链接的应用程序可用。

 

当在定义了 _STATIC_CPPLIB (/D_STATIC_CPPLIB) 的情况下使用 /MD 时，它将导致应用程序通过静态多线程标准 C++ 库 (libcpmt.lib) 而非动态版本 (msvcprt.lib) 进行链接，同时仍通过 msvcrt.lib 动态链接到主 CRT。

/MDd      定义 _DEBUG、_MT 和 _DLL，以便从标准 .h 文件中选择运行时例程的调试多线程特定版本和 DLL 特定版本。它还使编译器将库名 MSVCRTD.lib 放入 .obj 文件中。
/ML 使编译器将库名 LIBC.lib 放入 .obj 文件中，以便链接器使用 LIBC.lib 解析外部符号。这是编译器的默认操作。LIBC.lib 不提供多线程支持。

 

/MLd     定义 _DEBUG 并使编译器将库名 LIBCD.lib 放入 .obj 文件中，以便链接器使用 LIBCD.lib 解析外部符号。LIBCD.lib 不提供多线程支持。

 

/MT      定义 _MT， 以便从标准头 (.h) 文件中选择运行时例程的多线程特定版本。此选项还使编译器将库名 LIBCMT.lib 放入 .obj 文件中，以便链接器使用 LIBCMT.lib 解析外部符号。创建多线程程序需要 /MT 或 /MD（或它们的调试等效选项 /MTd 或 /MDd）。

 

/MTd     定义 _DEBUG 和 _MT。定义 _MT 会导致从标准 .h 文件中选择运行时例程的多线程特定版本。此选项还使编译器将库名 LIBCMTD.lib 放入 .obj 文件中，以便链接器使用 LIBCMTD.lib 解析外部符号。创建多线程程序需要 /MTd 或 /MDd（或它们的非调试等效选项 /MT 或 MD）。

 

/LD      创建 DLL。
将 /DLL 选项传递到链接器。链接器查找 DllMain 函数，但并不需要该函数。如果没有编写 DllMain 函数，链接器将插入返回 TRUE 的 DllMain 函数。

 

/LDd    创建调试 DLL。定义 _DEBUG。

 

警告:   

 

       不要混合使用运行时库的静态版本和动态版本。在一个进程中有多个运行时库副本会导致问题，因为副本中的静态数据不与其他副本共享。链接器禁止在 .exe 文件内部既使用静态版本又使用动态版本链接，但您仍可以使用运行时库的两个（或更多）副本。例如，当与用动态 (DLL) 版本的运行时库链接的 .exe 文件一起使用时，用静态（非 DLL）版本的运行时库链接的动态链接库可能导致问题。（还应该避免在一个进程中混合使用这些库的调试版本和非调试版本）。