剛開始接觸VC的時候，很大一部分時間是在對付編譯鏈接錯誤，因爲經驗不足的原因，這些編譯鏈接總讓人很沮喪。比如：
1.fatal error LNK1104: 無法打開文件“LIBC.lib”錯誤
這個錯誤是因爲庫衝突導致的，解決方法如下：
方法一：
用VSDNET2005重新編譯某個工程的發生了鏈接錯誤
現在把這個解決過程分享一下。
錯誤如下：fatal error LNK1104: 無法打開文件“LIBC.lib” 。
解決如下：項目->屬性中->配置屬性->鏈接器->輸入->在忽略特定庫中寫入打不開的文件的名稱LIBC.lib;
方法二：
在stdafx.h 里加上這句吧
#pragma comment (linker,"/NODEFAULTLIB:libc.lib")
其實和1是一樣的
方法三：
下一個libc.lib，或者把VC6.0中的包含進來
查了一下資料，能發現
LIBC.LIB Single-threaded, static link /ML
LIBCMT.LIB Multithreaded, static link /MT _MT
MSVCRT.LIB Multithreaded, dynamic link (import library for MSVCR71.DLL).
下面提供兩種解決方案，如果想根治鏈接的這種錯誤，而也有被鏈接的庫的源代碼，使他們一致即可：
方法一：
- “項目屬性” -> “配置屬性” -> “C/C++” -> “代碼生成”中的“運行時庫”，設置成“/MT (static link )”
方法二：
2. “項目屬性” -> “配置屬性” -> “鏈接器” -> “輸入”中的“所有默認庫”，設置成“/NODEFAULTLIB (static link )”
2.error C2220: 警告被視爲錯誤 - 沒有生成“object”文件
這種錯誤的原因是：原因是該文件的代碼頁爲英文，而我們系統中的代碼頁爲中文。
解決方案：
1. 啓動Microsoft Visual Studio 2005，文件->打開->選擇該cpp，然後保存。從新打開程序文件運行，此錯誤不再出現。
如果不行， 則 2
2. 如果上述不能去掉錯誤，還可以點擊項目，右擊選擇屬性->配置屬性->c/c++->常規，將“警告視爲錯誤”的選項改爲“否”。就可以！
3.關於形如--error LNK2005: xxx 已經在 msvcrtd.lib ( MSVCR90D.dll ) 中定義的問題
如果你使用的操作系統是 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」用途分成兩個版本之外，兩者又可分別衍生分出「靜態鏈接」與「動態鏈接」兩種形式：
靜態鏈接：
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 的預設選項則會使用動態鏈接的版本。
C Runtime Library
請注意，以上只是單純 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 二者。
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>等方法。筆者未嘗試過第二種方法，但是第一種倒是確實好用。第二種不推薦，因爲如果使用了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。
4.“error LNK2019: 無法解析的外部符號 _main，該符號在函數 ___tmainCRTStartup 中被引用”解決方法。
在VS2008中使用MFC，程序生成時遇到如下錯誤：error LNK2019: 無法解析的外部符號 _main，該符號在函數
___tmainCRTStartup 中被引用，LIBCMTD.lib。
打開BuildLog（在Debug目錄下面），會看到如下：
1>LINK : warning LNK4098: 默認庫“msvcrtd.lib”與其他庫的使用衝突；請使用 /NODEFAULTLIB:library
1>LINK : warning LNK4098: 默認庫“LIBCMTD”與其他庫的使用衝突；請使用 /NODEFAULTLIB:library
1>LIBCMTD.lib(crt0.obj) : error LNK2019: 無法解析的外部符號 _main，該符號在函數 ___tmainCRTStartup 中被引用
解決方法：忽略LIBCMTD.lib庫。
VC2008步驟：主菜單“項目”， “屬性”， “配置屬性”， “鏈接器”， “輸入”， “忽略特定庫”， 添加庫“LIBCMTD.lib”，即可。