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

[email protected]”的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？

[email protected]@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的執行期庫放在前面即可！