轉自https://www.cnblogs.com/qinfengxiaoy
1.問題引出
很久沒有寫程序設計入門知識的相關文章了，這篇文章要來談談程序庫 (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？在我們的程序代碼中有使用這些程序
庫嗎？
答是肯定的。
2.C Runtime Library（C運行時庫）
熟悉 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」用途分成兩個版本之外，兩者又可分別
衍生分出「靜態鏈接」與「動態鏈接」兩種形式：
靜態鏈接：
LIBCMTD.lib（Debug版本）
LIBCMT.lib
動態鏈接：
MSVCRTD.lib（Debug版本）
MSVCRT.lib
雖然這四個 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 鏈接版本的地方。其中總共有四個選項，正好對應於上述靜態鏈接與動態鏈接的四個不同
程序庫版本。
多執行線程調試 (/MTd)：對應 LIBCMTD.lib
多執行線程 (/MT)：對應 LIBCMT.lib
多執行線程調試 DLL (/MDd)：對應 MSVCRTD.lib
多執行線程 DLL (/MD)：對應 MSVCRT.lib
如果你沒有做任何設定就開始生成程序的話，MSVC 的預設選項則會使用動態鏈接的版本。
3.Standard C++ Library（標準C++庫）
請注意，以上只是單純 C 語言的程序庫而沒有包含 C++ 語言在內。如果你的程序系統中，有包含 C++ 語言的程序代碼的
話，那又是另外一回事了。但是在項目屬性的頁面中，爲什麼找不到相關的設定選項呢？因爲 MSVC 悄悄地幫程序設計者代勞
處理掉了。只要在程序代碼中使用 #include 語法納入任何一個 C++ 的標頭文件，例如 iostream 或 fstream，MSVC 就
會在鏈接器的運作階段中，自動幫我們鏈接 C++ 的執行階段程序庫。而 C++ 的執行階段程序庫，同樣可分爲四個版本：
靜態鏈接：
LIBCPMTD.lib（Debug版本）
LIBCPMT.lib
動態鏈接：
MSVCPRTD.lib（Debug版本）：執行文件相依於 MSVCP90D.dll
MSVCPRT.lib：執行文件相依於 MSVCP90.dll
至於程序執行文件使用的是靜態鏈接或者動態鏈接的版本，就仰賴於 C 語言的版本設定選項了。舉個例子來說，如果你撰寫了
一個 Debug 組態的 C++ 程序，並且保留項目原先預設的生成選項（動態鏈接），那麼最終生成出來的程序執行文件將會相
依於 MSVCR90D.dll 以及 MSVCP90D.dll 兩個 DLL 文件。如果將相同的程序以 Release 組態生成完成，則會相依於
MSVCR90.dll 以及 MSVCP90.dll 二者。
4.問題分析及解決
剛學習程序設計的入門者，經常會在滿心歡喜地完成一件程序作品並且傳給其他人使用時，卻發現不能在別人的電腦上啓動程
序，其實就是陷入了使用者電腦缺少 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編譯參數吧。這次之所以沒有使用它，也是爲了嚴謹起見。