http://pengxzh.bokee.com/viewdiary.11923681.html
LNK2001
學習VC＋＋時經常會遇到鏈接錯誤LNK2001，該錯誤非常討厭，因爲對於
編程者來說，最好改的錯誤莫過於編譯錯誤，而一般說來發生連接錯誤時，
編譯都已通過。產生連接錯誤的原因非常多，尤其LNK2001錯誤，常常使人不
明其所以然。如果不深入地學習和理解VC＋＋，要想改正連接錯誤LNK2001非
常困難。
初學者在學習VC＋＋的過程中，遇到的LNK2001錯誤的錯誤消息主要爲：
unresolved external symbol “symbol”（不確定的外部“符號”）。
如果連接程序不能在所有的庫和目標文件內找到所引用的函數、變量或
標籤，將產生此錯誤消息。一般來說，發生錯誤的原因有兩個：一是所引用
的函數、變量不存在、拼寫不正確或者使用錯誤；其次可能使用了不同版本
的連接庫。
以下是可能產生LNK2001錯誤的原因：
一．由於編碼錯誤導致的LNK2001。
1．不相匹配的程序代碼或模塊定義（.DEF）文件能導致LNK2001。例如,
如果在C＋＋ 源文件內聲明瞭一變量“var1”，卻試圖在另一文件內以變量
“VAR1”訪問該變量,將發生該錯誤。
2．如果使用的內聯函數是在.CPP文件內定義的，而不是在頭文件內定
義將導致LNK2001錯誤。
3．調用函數時如果所用的參數類型同函數聲明時的類型不符將會產生
LNK2001。
4．試圖從基類的構造函數或析構函數中調用虛擬函數時將會導致LNK2001。
5．要注意函數和變量的可公用性，只有全局變量、函數是可公用的。
靜態函數和靜態變量具有相同的使用範圍限制。當試圖從文件外部訪問
任何沒有在該文件內聲明的靜態變量時將導致編譯錯誤或LNK2001。
函數內聲明的變量（局部變量） 只能在該函數的範圍內使用。
C＋＋ 的全局常量只有靜態連接性能。這不同於C，如果試圖在C＋＋的
多個文件內使用全局變量也會產生LNK2001錯誤。一種解決的方法是需要時在
頭文件中加入該常量的初始化代碼，並在.CPP文件中包含該頭文件；另一種
方法是使用時給該變量賦以常數。
二．由於編譯和鏈接的設置而造成的LNK2001
1．如果編譯時使用的是/NOD（/NODEFAULTLIB）選項，程序所需要的運行
庫和MFC庫在連接時由編譯器寫入目標文件模塊， 但除非在文件中明確包含
這些庫名，否則這些庫不會被鏈接進工程文件。在這種情況下使用/NOD將導
致錯誤LNK2001。
2．如果沒有爲wWinMainCRTStartup設定程序入口，在使用Unicode和MFC
時將得到“unresolved external on _WinMain@16”的LNK2001錯誤信息。
3．使用/MD選項編譯時,既然所有的運行庫都被保留在動態鏈接庫之內，
源文件中對“func”的引用，在目標文件裏即對“__imp__func” 的引用。
如果試圖使用靜態庫LIBC.LIB或LIBCMT.LIB進行連接，將在__imp__func上發
生LNK2001；如果不使用/MD選項編譯，在使用MSVCxx.LIB連接時也會發生LNK2001。
4．使用/ML選項編譯時，如用LIBCMT.LIB鏈接會在_errno上發生LNK2001。
5．當編譯調試版的應用程序時，如果採用發行版模態庫進行連接也會產
生LNK2001；同樣，使用調試版模態庫連接發行版應用程序時也會產生相同的
問題。
6．不同版本的庫和編譯器的混合使用也能產生問題，因爲新版的庫裏可
能包含早先的版本沒有的符號和說明。
7．在不同的模塊使用內聯和非內聯的編譯選項能夠導致LNK2001。如果
創建C＋＋庫時打開了函數內聯（/Ob1或/Ob2），但是在描述該函數的相應頭
文件裏卻關閉了函數內聯（沒有inline關鍵字），這時將得到該錯誤信息。
爲避免該問題的發生，應該在相應的頭文件中用inline關鍵字標誌內聯函數。
8．不正確的/SUBSYSTEM或/ENTRY設置也能導致LNK2001。
其實，產生LNK2001的原因還有很多，以上的原因只是一部分而已，對初
學者來說這些就夠理解一陣子了。但是，分析錯誤原因的目的是爲了避免錯
誤的發生。LNK2001錯誤雖然比較困難，但是隻要注意到了上述問題，還是能
夠避免和予以解決的。
VC++的鏈接錯誤LNK2005
編程中經常能遇到LNK2005錯誤——重複定義錯誤，其實LNK2005錯誤並不是一個很難解決的錯誤。弄清楚它形成的原因，就可以輕鬆解決它了。
造成LNK2005錯誤主要有以下幾種情況：
1． 重複定義全局變量。可能存在兩種情況：
A、 對於一些初學編程的程序員，有時候會以爲需要使用全局變量的地方就可以使用定義申明一下。其實這是錯誤的，全局變量是針對整個工程的。正確的應該是在一個CPP文件中定義如下：int g_Test;那麼在使用的CPP文件中就應該使用：extern int g_Test即可，如果還是使用int g_Test，那麼就會產生LNK2005錯誤，一般錯誤錯誤信息類似：AAA.obj error LNK2005 int book c？book@@3HA already defined in BBB.obj。切記的就是不能給變量賦值否則還是會有LNK2005錯誤。
這裏需要的是“聲明”，不是“定義”！根據C++標準的規定，一個變量是聲明，必須同時滿足兩個條件，否則就是定義：
(1)聲明必須使用extern關鍵字；(2)不能給變量賦初值
所以，下面的是聲明:
extern int a;
下面的是定義
int a; int a = 0; extern int a =0;
B、對於那麼編程不是那麼嚴謹的程序員，總是在需要使用變量的文件中隨意定義一個全局變量，並且對於變量名也不予考慮，這也往往容易造成變量名重複，而造成LNK2005錯誤。
2． 頭文件的包含重複。往往需要包含的頭文件中含有變量、函數、類的定義，在其它使用的地方又不得不多次包含之，如果頭文件中沒有相關的宏等防止重複鏈接的措施，那麼就會產生LNK2005錯誤。解決辦法是在需要包含的頭文件中做類似的處理：#ifndef MY_H_FILE //如果沒有定義這個宏
#define MY_H_FILE //定義這個宏
……. //頭文件主體內容
…….
#endif
上面是使用宏來做的，也可以使用預編譯來做，在頭文件中加入：
#pragma once
//頭文件主體
3． 使用第三方的庫造成的。這種情況主要是C運行期函數庫和MFC的庫衝突造成的。具體的辦法就是將那個提示出錯的庫放到另外一個庫的前面。另外選擇不同的C函數庫，可能會引起這個錯誤。微軟和C有兩種C運行期函數庫，一種是普通的函數庫：LIBC.LIB，不支持多線程。另外一種是支持多線程的：msvcrt.lib。如果一個工程裏，這兩種函數庫混合使用，可能會引起這個錯誤，一般情況下它需要MFC的庫先於C運行期函數庫被鏈接，因此建議使用支持多線程的msvcrt.lib。所以在使用第三方的庫之前首先要知道它鏈接的是什麼庫，否則就可能造成LNK2005錯誤。如果不得不使用第三方的庫，可以嘗試按下面所說的方法修改，但不能保證一定能解決問題，前兩種方法是微軟提供的：
A、 選擇VC菜單Project->Settings->Link->Catagory選擇Input，再在Ignore libraries 的Edit欄中填入你需要忽略的庫，如：Nafxcwd.lib;Libcmtd.lib。然後在Object/library Modules的Edit欄中填入正確的庫的順序，這裏需要你能確定什麼是正確的順序，呵呵，God bless you！
B、 選擇VC菜單Project->Settings->Link頁，然後在Project Options的Edit欄中輸入/verbose:lib，這樣就可以在編譯鏈接程序過程中在輸出窗口看到鏈接的順序了。
C、 選擇VC菜單Project->Settings->C/C++頁，Catagory選擇Code Generation後再在User Runtime libraray中選擇MultiThread DLL等其他庫，逐一嘗試。
關於編譯器的相關處理過程，參考：
http://www.donews.net/xzwenlan/archive/2004/12/23/211668.aspx
這就是我所遇到過的LNK2005錯誤的幾種情況，肯定還有其他的情況也可能造成這種錯誤，所以我不希望你在看完這篇文章以後，再遇到LNK2005錯誤時候，不動腦筋的想對號入座的排除錯誤。編程的過程就是一個思考的過程，所以還是多多開動你的頭腦，那樣收穫會更多！
---------------------------------------------------------------
支持,我在社區裏也看到了許多LINK 2005錯
補充一點,就是一次在用第三方庫時,由於errno被重定義,用多種方法都不能解決,後查找MSDN,發現link有個選項/FORCE可以解決,在IDE下
Project->Settings->Link頁,選categroy爲custom,將force file output前打勾
但會有警告
warning LNK4088: image being generated due to /FORCE option; image may not run
但的確解決了問題,這是由於VC對重定義比較嚴格,像BCB或GCC在庫中的重定義不會有任何警告或錯誤
--------------------------------------------------------------
使用第三方庫,最好用編譯時的運行庫方式,保持一致
---------------------------------------------------------------
我發現的另外一個出現LINK2005的現象，好像是由於名稱空間而引起的。我在dos下寫的程序沒有問題，但是放在mfc中就出現了這個鏈接錯誤。因爲起初圖省事，我在一個頭文件中寫了using namespace std,並且這個頭文件我多處使用，另外，我還使用了boost庫。後來，問題解決的方法非常奇怪，在一個頭文件中引用其他頭文件，這些頭文件的順序換一下就通過了，那個出現問題的頭文件中我使用了std::map，當我把這種容器使用模板代替後，鏈接就有沒事了。（例如：template<class coll>）,後來感到模板技術還有這種效果,賺了!哈哈
---------------------------------------------------------------
#pragma comment( linker, "/NODEFAULTLIB:msvcprtd.lib" )
#pragma comment( linker, "/NODEFAULTLIB:libcmtd.lib" )
#pragma comment( linker, "/NODEFAULTLIB:msvcprt.lib" )
#pragma comment( linker, "/NODEFAULTLIB:libcmt.lib" )
#ifdef _UNICODE
#pragma comment( linker, "/ENTRY:wWinMainCRTStartup" )
#endif
#ifdef _DEBUG
#pragma comment( lib, "cryptlibd" )
#else
#pragma comment( lib, "cryptlib" )
#endif
---------------------------------------------------------------
我發現的另外一個出現LINK2005的現象，好像是由於名稱空間而引起的。我在dos下寫的程序沒有問題，但是放在mfc中就出現了這個鏈接錯誤。因爲起初圖省事，我在一個頭文件中寫了using namespace std,並且這個頭文件我多處使用，另外，我還使用了boost庫。後來，問題解決的方法非常奇怪，在一個頭文件中引用其他頭文件，這些頭文件的順序換一下就通過了，那個出現問題的頭文件中我使用了std::map，當我把這種容器使用模板代替後，鏈接就有沒事了。（例如：template<class coll>）,後來感到模板技術還有這種效果,賺了!哈哈
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
這種情況好像就是因爲庫的版本衝突造成的。標準的C＋＋庫使用C運行期函數庫。MFC使用了自己的C運行期函數庫。調整頭文件的順序也就是調整鏈接庫的順序。在這種情況下一般是將MFC的運行期庫放在前面即可！