[转]关于形如--error LNK2005: xxx 已经在 msvcrtd.lib ( MSVCR90D.dll
（ 不知哪个大神写的！非常有益！阅读前需要对静态库（.lib）、动态库（.dll）、导入库（这个还是.lib）之间的区别联系有了解。建议先读读宋宝华先生的《VC++动态链接库(DLL)编程深入浅出 》）
关键词：程序库、CRT、LIBCMTD.lib、MSVCRTD.lib、链接库的冲突问题、MSVC链接处理
很久没有写程序设计入门知识的相关文章了，这篇文章要来谈谈程序库 (Library) 链接，以及关于 MSVC 与 CRT 之间的种种恩怨情仇。
如果你使用的操作系统是 Linux、Mac 或其他非 Windows 平台，你可以忽略这篇文章；如果你使用的操作系统是 Windows 平台，但没有用 Microsoft Visual Studio C++（以下简称为 MSVC）软件撰写 C++ 程序的话，这篇文章对你的帮助可能很有限；但如果你的操作系统是 Windows，而且你使用的程序整合开发环境是 MSVC 软件撰写 C++ 程序的话，这篇文章应该能够帮助你釐清一些重要的基础观念。
身为程序设计者，在学习程序设计的过程中，你是否曾经遇过某些看起来不知所云的错误信息，却不知该如何解决？例如当你快快乐乐地写完程序，并且确认所有的程序代码都能成功通过编译之后，接着执行「生成解决方案」(Build Solution) 的步骤，结果却跑出一堆莫名其妙的错误：
1>libcmtd.lib(errmode.obj) : error LNK2005: ___set_app_type 已经在msvcrtd.lib(MSVCR90D.dll) 中定义
1>libcmtd.lib(dbgrptw.obj) : error LNK2005: __CrtDbgReport已经在msvcrtd.lib(MSVCR90D.dll) 中定义
1>msvcrtd.lib(MSVCR90D.dll) : error LNK2005: __setmbcp 已经在libcmtd.lib(mbctype.obj) 中定义
1>LINK:warning LNK4098:默认库“msvcrtd.lib”与其他库的使用冲突；请使用/NODEFAULTLIB:library
1>msvcrtd.lib(cinitexe.obj) : warning LNK4098: 默认库“libcmtd.lib”与其他库的使用冲突；请使用/NODEFAULTLIB:library
.....................
以一般的情况来说，如果在你的程序项目中有使用某些由他人所撰写的第三方程序库或是开源项目的程序库，比较容易会发生上述的错误状况。从上述这些看似离奇而令人摸不着头线程的错误信息中，我们大概可以猜测问题点应该在于 LIBCMTD.lib 与 MSVCRTD.lib 这两个程序库身上。但到底什么是 LIBCMTD.lib 和 MSVCRTD.lib？在我们的程序代码中有使用这些程序库吗？
答是肯定的。
熟悉 C 语言的程序设计者都知道，如果要使用 printf()、scanf() 或者 fopen() 等等 C 语言的基本 I/O 操作函数时，首先必须用 #include 语法将 stdio.h 这个标头文件纳入我们的程序代码中。藉由 stdio.h 中对这些 I/O 操作函数所做出的函数声明 (function declaration)，编译器 (Compiler) 才得以确认 printf、scanf 以及 fopen 等等都是合法可用的函数。
而当我们撰写的程序代码经过编译器产出 OBJ 形式的文件之后，需要再经由链接器 (Linker) 的处理程序，将程序代码中全部有使用到的函数定义 (function definition) 链接生成起来，才能够产生出最后的程序执行文件。问题来了，我们知道 printf、scanf 以及 fopen 的函数声明存在于 stdio.h 当中，但是这些傢伙的函数定义，也就是真正的定义程序代码，究竟存放在什么地方呢？
在 C 语言的标准程序库中。
由 C 语言所制订的标准程序库，称之为「执行阶段程序库」，也就是 C Run-Time Library，通常可简称为 CRT。在 C 语言的标准程序库中，包含了一组常用的基础函数，例如 I/O 处理与字串操作程序等等，所以只要我们使用 C 语言撰写程序代码，就一定要将编译完成后的程序代码 OBJ 文件，链接至 C 语言的执行阶段程序库，才能够产生出合法的 C 语言程序执行文件。
而 CRT 并非只有单一一种版本存在。事实上，除了可以依「Debug」与「Release」用途分成两个版本之外，两者又可分别衍生分出「静态链接」与「动态链接」两种形式：
静态链接：
动态链接：
虽然这四个 CRT 版本的用途与使用方式各不相同，但却有个共通的特点，就是它们都是满足执行线程安全需求，可在多执行线程程序代码中安全使用的程序库版本。事实上，在过去 MSVC 6 的版本中，本来还有另外两个 LIBCD.lib（Debug版本）与 LIBC.lib 程序库，是专门给单执行线程程序使用的 CRT 版本，但是这两个选项自 MSVC 2005 开始就从设定选项中被删除掉了，所以现在大多数程序设计者使用的都是多执行线程的 CRT 版本。
在程序库链接 (library linking) 的行为中，静态链接和动态链接的分别，在于使用静态链接时，会直接将程序库的函数定义嵌入执行文件之中，而使用动态链接时，程序库的函数定义则存在于另外的独立文件，通常是 DLL 格式的文件中，然后与程序执行文件一同发布给使用者。因此在文件的尺寸上，使用动态链接的执行文件文件，通常会比使用静态链接的执行文件文件更小一些。
使用动态链接 CRT 版本的好处，是能够将经常使用到的标准程序库们独立出来，放在 Windows 的系统文件夹中，以减少我们生成出来的执行文件文件尺寸。但反过来说，使用动态链接 CRT 版本的缺点也在于这些与执行文件相依为命的 DLL 文件上。举例来说，如果程序以 MSVC 2005 生成出 Debug 态的执行文件，则此执行文件需要有 msvcr80d.dll 存在才能顺利执行；如果是 Release 态，则相依于 msvcr80.dll。但是如果你把相同的程序代码拿到 MSVC 2008 上生成，产生出来的执行文件则相依于 msvcr90d.dll 与 msvcr90.dll 两个不同的 DLL 文件。不同版本的 MSVC，都会有各自不同的相依 DLL 文件。
在 MSVC 的程序项目中，如何指定程序代码要使用静态链接或者动态链接的 CRT 版本？其实很容易，只要在项目属性的「C/C++」页面中，选择「程序代码产生」(Code Generation) 子页面，其中有个「执行阶段程序库」(Runtime Library) 的项目，也就是项目中用来设定 CRT 链接版本的地方。其中总共有四个选项，正好对应于上述静态链接与动态链接的四个不同程序库版本。
如果你没有做任何设定就开始生成程序的话，MSVC 的预设选项则会使用动态链接的版本。
C Runtime Library
请注意，以上只是单纯 C 语言的程序库而没有包含 C++ 语言在内。如果你的程序系统中，有包含 C++ 语言的程序代码的话，那又是另外一回事了。但是在项目属性的页面中，为什么找不到相关的设定选项呢？因为 MSVC 悄悄地帮程序设计者代劳处理掉了。只要在程序代码中使用 #include 语法纳入任何一个 C++ 的标头文件，例如 iostream 或 fstream，MSVC 就会在链接器的运作阶段中，自动帮我们链接 C++ 的执行阶段程序库。而 C++ 的执行阶段程序库，同样可分为四个版本：
静态链接：
动态链接：
至于程序执行文件使用的是静态链接或者动态链接的版本，就仰赖于 C 语言的版本设定选项了。举个例子来说，如果你撰写了一个 Debug 组态的 C++ 程序，并且保留项目原先预设的生成选项（动态链接），那么最终生成出来的程序执行文件将会相依于 MSVCR90D.dll 以及 MSVCP90D.dll 两个 DLL 文件。如果将相同的程序以 Release 组态生成完成，则会相依于 MSVCR90.dll 以及 MSVCP90.dll 二者。
Standard C++ Library
刚学习程序设计的入门者，经常会在满心欢喜地完成一件程序作品并且传给其他人使用时，却发现不能在别人的电脑上启动程序，其实就是陷入了使用者电脑缺少 DLL文件而无法执行程序的窘境。有三种方法可以解决这个令人困扰的问题：
1 . 使用者的电脑，必须先安装「Visual C++开发套件」（MSVC 2008 或 MSVC 2005 ）。
2 . 将所需的 DLL文件，例如 MSVCR90D.dll与MSVCP90.dll，直接附在程序的下载包当中。
3 . 以静态链接方式生成程序执行文件。
当你无法确定自己的程序或别人的程序，是否相依于某些特定的 DLL文件时，有一个非常好用的免费工具程序 Dependency Walker，可以开启 EXE格式的执行文件或者 DLL格式的动态程序库，然后详细地条列出它们所相依的 DLL文件。
了解了几种不同的 CRT版本选项之后，回到最前面的错误信息问题，相信各位现在应该能够很清楚地理解，原来会发生这些奇怪的错误状况，是因为程序同时链接了 LIBCMTD.lib与MSVCRTD.lib而造成函数定义版本冲突。也就是说，程序链接器已经在其中一个 CRT的版本中找到所需的函数定义，但此时却又跳出另外一位 CRT，也给了一份相同函数的实现版本，所以链接器无法判断应该忽略谁并且选择谁。
而这个状况的发生原因，就是你的程序与程序所链接的外部程序库，使用了不同的 CRT版本之故。例如，当你的程序使用了 Lua，自然必须链接至 Lua的程序库 lua5.1.lib，但如果lua5.1.lib是以静态链接版本的 CRT生成而成，而你的程序却是以预设选项，动态链接 CRT 来生成程序执行文件的话，如此一来就会产生上述这些错误信息了。至此，问题的答已昭然若揭，解决方法有二种：其一是将 Lua重新以动态链接 CRT 的方式生成出一个新的程序库，其二则是将自己的程序项目改成以静态链接 CRT 方式生成。
换个角度想，当你身为一位程序库的设计开发者，想要将自己写的东西分享给其他人，但又不想要完全开放自己撰写的程序源码时，至少可以同时提供以下四种版本的程序库，以妥善满足使用者的各种不同需求：
Debug：动态链接Debug版本
Release：动态链接版本
Debug_Static：静态链接Debug版本
Release_Static：静态链接版本
然而，有时候世界并不会运作得如此理想。在某些特殊的状况下，当我们使用他人所写的第三方程序库时，有时可能只拿得到其中某个特定的版本，例如 Release_Static版本时，就很有可能会遇到程序库冲突的错误情形。此时就需要视项目的实际需求而定，可以在项目属性中指定「忽略特定程序库」(Ignore Specific Library)这个选项，让程序代码链接器忽略某些程序库，以此化解动静程序库或新旧程序库之间的恩怨冲突。
小测验：你所撰写的程序，必须链接某个以静态多执行线程 (/MT) CRT 生成而成的程序库。如果你的程序在 Debug组态下以多执行线程侦错 (/MTd)选项生成，是否会产生冲突？如果你的程序在 Release组态下以多执行线程 (/MT) 选项生成，是否会产生冲突？是的话，应该如何解决？
上面的方法还是不行！会出现其他问题的。
以下是我摸索出的最新的解决方法：
首先，所有的lib文件，使用/MTd或/MT编译（注：即静态链接模式）。Debug调试模式使用/MTd，Release模式使用/MT。
然后，在自己的程序中也使用/MTd或/MT编译。这样就不会出问题了。
三种编译链接库的方式：
（1）连接Windows库。针对Win32 API编写的应用程序，上面的方法可能带来新问题，可以忽略libcmt.lib库，即可。如果还有其他问题，再忽略相应的库。
（2）MFC静态链接。上面的方法就是针对这种链接方式的，所以没问题。
（3）MFC动态链接。没有试过，应该和（1）类似。
最后补充：如果还不行，直接加入/force:multiple编译参数吧。这次之所以没有使用它，也是为了严谨起见。
完美解决#define _AFXDLL or do not
use
这个问题经常出现在尝试使用Visual Studio 较高版本（2008,2010）编辑较低版本（Visual C++ 6.0）时使用“在静态库中使用MFC”的情况。在·在网上查找方法，无非是“改成在共享DLL中使用MFC”，或者将#include 改成等方法。笔者未尝试过第二种方法，但是第一种倒是确实好用。第二种不推荐，因为如果使用了afx.h中的函数和变量，atlstr.h没有怎么办？
解决方案：项目属性（Alt+F7）——C/C++——代码生成——
如果是Debug的“在静态库中使用MFC”，不要使用MDd，改用MTd，然后编译即可通过。
如果是Debug的“在共享DLL中使用MFC”，注意不要使用MTd，改用MDd；
如果是Release版本“在静态库中使用MFC”，不要使用MD，使用MT；
如果是Release版本的“在共享DLL中使用MFC”，不要使用MT，使用MD。
