很久没有写程式设计入门知识的相关文章了，这篇文章要来谈谈程式库 (Library) 连结，以及关于 MSVC 与 CRT 之间的种种恩怨情仇。
如果你使用的作业系统是 Linux、Mac 或其他非 Windows 平台，你可以忽略这篇文章；如果你使用的作业系统是 Windows 平台，但没有用 Microsoft Visual Studio C++（以下简称为 MSVC）软体撰写 C++ 程式的话，这篇文章对你的帮助可能很有限；但如果你的作业系统是 Windows，而且你使用的程式整合开发环境是 MSVC 软体撰写 C++ 程式的话，这篇文章应该能够帮助你釐清一些重要的基础观念。
身为程式设计者，在学习程式设计的过程中，你是否曾经遇过某些看起来不知所云的错误讯息，却不知该如何解决？例如当你快快乐乐地写完程式，并且确认所有的程式码都能成功通过编译之后，接着执行「建置方案」(Build Solution) 的步骤，结果却跑出一堆莫名其妙的错误：
LIBCMTD.lib(mlock.obj) : error LNK2005: __lock 已在 MSVCRTD.lib(MSVCR80D.dll) 中定义过了
LIBCMTD.lib(mlock.obj) : error LNK2005: __unlock 已在 MSVCRTD.lib(MSVCR80D.dll) 中定义过了
LIBCMTD.lib(crt0.obj) : error LNK2005: _mainCRTStartup 已在 MSVCRTD.lib(crtexe.obj) 中定义过了…………
LINK : warning LNK4098: 预设的程式库 ‘MSVCRTD’ 与其他使用的程式库冲突，请使用 /NODEFAULTLIB:library
LINK : warning LNK4098: 预设的程式库 ‘LIBCMTD’ 与其他使用的程式库冲突，请使用 /NODEFAULTLIB:library
D:\Workspace\CrtLibTest\Debug\CrtLibTest.exe : fatal error LNK1169: 找到有一或多个已定义的符号
以一般的情况来说，如果在你的程式专案中有使用某些由他人所撰写的第三方程式库或是开源专案的程式库，比较容易会发生上述的错误状况。从上述这些看似离奇而令人摸不着头绪的错误讯息中，我们大概可以猜测问题点应该在于 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 并非只有单一一种版本存在。事实上，除了可以依「除错」与「释出」用途分成两个版本之外，两者又可分别衍生分出「静态连结」与「动态连结」两种形式：
静态连结：
- LIBCMTD.lib（除错版本）
- LIBCMT.lib
动态连结：
- MSVCRTD.lib（除错版本）
- MSVCRT.lib
虽然这四个 CRT 版本的用途与使用方式各不相同，但却有个共通的特点，就是它们都是满足执行绪安全需求，可在多执行绪程式码中安全使用的程式库版本。事实上，在过去 MSVC 6 的版本中，本来还有另外两个 LIBCD.lib（除错版本）与 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 连结版本的地方。其中总共有四个选项，正好对应于上述静态连结与动态连结的四个不同程式库版本。
- 多执行绪侦错 (/MTd)：对应 LIBCMTD.lib
- 多执行绪 (/MT)：对应 LIBCMT.lib
- 多执行绪侦错 DLL (/MDd)：对应 MSVCRTD.lib
- 多执行绪 DLL (/MD)：对应 MSVCRT.lib
如果你没有做任何设定就开始建置程式的话，MSVC 的预设选项则会使用动态连结的版本。
C Runtime Library
请注意，以上只是单纯 C 语言的程式库而没有包含 C++ 语言在内。如果你的程式系统中，有包含 C++ 语言的程式码的话，那又是另外一回事了。但是在专案属性的页面中，为什么找不到相关的设定选项呢？因为 MSVC 悄悄地帮程式设计者代劳处理掉了。只要在程式码中使用 #include 语法纳入任何一个 C++ 的标头档，例如 iostream 或 fstream，MSVC 就会在连结器的运作阶段中，自动帮我们连结 C++ 的执行阶段程式库。而 C++ 的执行阶段程式库，同样可分为四个版本：
静态连结：
- LIBCPMTD.lib（除错版本）
- LIBCPMT.lib
动态连结：
- MSVCPRTD.lib（除错版本）：执行档相依于 MSVCP90D.dll
- MSVCPRT.lib：执行档相依于 MSVCP90.dll
至于程式执行档使用的是静态连结或者动态连结的版本，就仰赖于 C 语言的版本设定选项了。举个例子来说，如果你撰写了一个 Debug 组态的 C++ 程式，并且保留专案原先预设的建置选项（动态连结），那么最终建置出来的程式执行档将会相依于 MSVCR90D.dll 以及 MSVCP90D.dll 两个 DLL 档案。如果将相同的程式以 Release 组态建置完成，则会相依于 MSVCR90.dll 以及 MSVCP90.dll 二者。
Standard C++ Library
刚学习程式设计的入门者，经常会在满心欢喜地完成一件程式作品并且传给其他人使用时，却发现不能在别人的电脑上启动程式，其实就是陷入了使用者电脑缺少 DLL 档案而无法执行程式的窘境。有三种方法可以解决这个令人困扰的问题：
- 使用者的电脑，必须先安装「Visual C++ 可转发套件」（MSVC 2008 或 MSVC 2005 ）。
- 将所需的 DLL 档案，例如 MSVCR90D.dll 与 MSVCP90D.dll，直接附在程式的下载包当中。
- 以静态连结方式建置程式执行档。
当你无法确定自己的程式或别人的程式，是否相依于某些特定的 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：动态连结除错版本
- Release：动态连结版本
- Debug_Static：静态连结除错版本
- 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>等方法。笔者未尝试过第二种方法，但是第一种倒是确实好用。第二种不推荐，因为如果使用了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。
from：http://www.cnblogs.com/minggoddess/archive/2010/12/29/1921077.html
