最近將兩個開源C++專案編譯成windows版本的時候遇到很多問題，關鍵是兩個專案經過同事的修改之後，一個專案引用了另一個專案，兩個專案的標頭檔案中都有一些跨平臺的關於資料型別，以及一些通用函式的定義，所以導致有衝突，編譯的時候總是報錯，報的最多的是“無法解析的外部符號”，經過近3天的折騰總算都通過了，這裡是一些總結。

首先，關於VC中的lib，與linux下的靜態庫是不同的，在VC中編譯動態庫的時候會生成一個lib和一個對應的dll，使用者在使用的時候需要包含標頭檔案以及連線到該lib，在釋出最終程式的時候則需要將對應的dll拷貝到釋出目錄。當然也可以使用LoadLibrary的方式在程式中動態載入dll而不需要使用這個動態庫生成的lib了。

如果是靜態庫，編譯之後只會生成一個lib檔案，該lib檔案非常大，可能有幾十M的大小，(而編譯動態庫的時候生成的lib可能只有幾十KB或者幾百KB)在使用這個靜態庫的lib的時候，也需要指定標頭檔案，與對應的lib庫檔案，編譯成功之後就可以直接執行，不需要拷貝額外的檔案了。

另外如果A是靜態庫，B是靜態庫，並且B使用了A的介面，這個時候在編譯B的時候只需要指定A的標頭檔案就可以了，不需要指定A的庫檔案。如果有一個專案C編譯成可執行檔案，C使用了B中的介面，這個時候在編譯C的時候，需要同時指定B的標頭檔案(如果該標頭檔案中又引用了A的標頭檔案那可能也要同時指定A的標頭檔案)，與B的lib庫檔案，以及A的lib庫檔案。 也就是說編譯C的時候要指定之前所有依賴的lib檔案。

在windows中編譯動態庫的時候，如果動態庫中的函式需要給別人使用，那麼這些函式或者類則需要被匯出，具體如下，假設庫的標頭檔案為A.h：

#  if defined LIB_A  //這個巨集為這個A特有的巨集
  #    define DLLEXP __declspec(dllexport)
  #  else
  #    define DLLEXP __declspec(dllimport)
  #  endif
  
  class DLLEXP ExportClass{
  //......
  };

如果在專案B中使用A庫，那麼專案B在引用A.h的時候，由於專案B沒有定義LIB_A這個巨集，所以實際上使用的是#define DLLEXP __declspec(dllimport)這個定義，也就是說在B專案中，這個ExportClass類的宣告變成匯入了，表示該類是從外部庫匯入的類。 而在專案A中由於定義了LIB_A這個專案特有的巨集，所以使用的是#define DLLEXP __declspec(dllexport)這個定義，說明需要編譯成匯出給別人用的類。

如果是C語言的庫給C++使用或者C++的庫封裝給C使用則除了要新增__declspec(dllexport)匯出宣告之外，還需要新增 external "C" 的宣告，該宣告主要告訴編譯器，編譯的時候生成的函式的符號表按照C的規則來生成。 因為C編譯器與C++編譯器生成符號表的時候規則是不一樣的。

那麼編譯的時候報告LINK錯誤，無法解析的外部符號，一般是下面幾種原因造成的：

1. 最常見的情況是要麼沒有指定引用庫的路徑，或者沒有指定所以依賴的庫檔名字。
2. 如果正確指定了lib庫路徑，以及lib庫名，那檢查一下該lib中是否有該符號的實現，也就是說標頭檔案中聲明瞭該符號，但是該庫檔案中卻沒有具體的實現。
3. 如果庫檔案中確實實現了符號的定義，那麼檢查一下lib庫的版本是否與正確(32位或者64位)。還有如果報告的是某一個函式無法解析，則要對比一下該函式在庫中的實現與在標頭檔案中的宣告是否一致(特別是函式的引數個數與引數型別是否完全一致)。
4. 有一種情況就是在編譯lib的時候，該lib是動態庫，但是沒有新增匯出宣告，導致該庫中的函式並不對外匯出(靜態庫不需要匯出宣告，加了反而會有問題)，那麼使用者在連結的時候也會報無法解析的符號。
5. 還有一種非常隱蔽的情況，這也是我遇到的情況，在專案A中將一些基本的資料型別做了typedef，例如類似下面的定義：

typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;

然後A專案的匯出函式 FUNC(uint8_t); 使用了該uint8_t，但是在B專案中對上述的 uint8_t 又做了另外一套定義 (如果A和B是兩個開源專案則很有可能出現這種衝突)，如下：

typedef unsigned __int8 uint8_t;

那麼在B中使用A的時候，使用的uint8_t是B的定義，實際上函式的宣告變成了 FUNC(unsigned __int8) 但是在A的lib庫檔案的實現裡面使用的是FUNC(unsigned char)也就是說該函式FUNC的宣告與定義並不匹配，那麼當然也會報告找不到符號了，這種情況一般是在兩個開源專案混合使用的時候就會出現衝突。

6. 編譯靜態庫的時候，如果靜態庫B引用了靜態庫A中的內容，此時在B的專案裡面都不需要指定A的庫路徑，只需要指定A的相關標頭檔案，就可以編譯通過，如果裡面有什麼問題，那麼會在最終使用B的專案的時候，連結的時候報出來。例如C專案使用了B，那麼在編譯C的時候需要同時新增A和B兩個庫，如果之前B使用A的過程中有問題的話，那麼在編譯C的時候就會報告LINK錯誤，而不是在編譯B的時候報告(除非是語法錯誤)。

7. 如果專案C使用了B庫與A庫，但是B與A是有依賴關係的，那麼在C的工程設定中，也要指定B和A的先後關係，否則也可能會報錯。

8. 如果在連線專案的時候報告下面的錯誤：

無法找到外部符號 _CrtDbgReportW 或者是
error LNK2038: 檢測到“_ITERATOR_DEBUG_LEVEL”的不匹配項: 值“2”不匹配值“0” (有可能是值"0"不匹配"2")

這種錯誤一般是在Release版本的專案中使用了Debug的庫，但是有時候明明看到我們編譯的庫都是Release版本的，使用那個庫的時候卻還是報告這個問題，這個現象可能是，編譯那個庫的時候，雖然選擇的是Release方式編譯，但是在專案的巨集定義中卻定義了_DEBUG巨集，導致該還是會被認為是Debug的版本。

VC中常見LINK錯誤及解決方案

. Windows子系統設定錯誤,提示:
libcmtd.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
Windows專案要使用Windows子系統,而不是Console,可以這樣設定:

[Project] --> [Settings] --> 選擇"Link"屬性頁,
在Project Options中將/subsystem:console改成/subsystem:windows

2. Console子系統設定錯誤,提示:
LIBCD.lib(wincrt0.obj) : error LNK2001: unresolved external symbol _WinMain@16

控制檯專案要使用Console子系統,而不是Windows,設定:

[Project] --> [Settings] --> 選擇"Link"屬性頁,
在Project Options中將/subsystem:windows改成/subsystem:console

3. 程式入口設定錯誤,提示:
msvcrtd.lib(crtexew.obj) : error LNK2001: unresolved external symbol _WinMain@16

通常,MFC專案的程式入口函式是WinMain,如果編譯專案的Unicode版本,程式入口必須改為wWinMainCRTStartup,所以需要重新設定程式入口:

[Project] --> [Settings] --> 選擇"Link"屬性頁,
在Category中選擇Output,
再在Entry-point symbol中填入wWinMainCRTStartup,即可

4. 執行緒執行時庫設定錯誤,提示:
nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __beginthreadex
nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __endthreadex

這是因為MFC要使用多執行緒時庫,需要更改設定:

[Project] --> [Settings] --> 選擇"C/C++"屬性頁,
在Category中選擇Code Generation,
再在Use run-time library中選擇Debug Multithreaded或者multithreaded
鹹魚遊俠(75374355) 12:11:11

其中,
Single-Threaded 單執行緒靜態連結庫(release版本)
Multithreaded 多執行緒靜態連結庫(release版本)
multithreaded DLL 多執行緒動態連結庫(release版本)
Debug Single-Threaded 單執行緒靜態連結庫(debug版本)
Debug Multithreaded 多執行緒靜態連結庫(debug版本)
Debug Multithreaded DLL 多執行緒動態連結庫(debug版本)

單執行緒: 不需要多執行緒呼叫時,多用在DOS環境下
多執行緒: 可以併發執行
靜態庫: 直接將庫與程式Link,可以脫離MFC庫執行
動態庫: 需要相應的DLL動態庫,程式才能執行
release版本: 正式釋出時使用
debug版本: 除錯階段使用

初學者在學習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．不同版本的庫和編譯器的混合使用也能產生問題，因為新版的庫裡可能包含早先的版本沒有的符號和說明。

　　程式設計時打開了函式內聯（/Ob1或/Ob2)，但是在描述該函式的相應標頭檔案裡卻關閉了函式內聯（沒有inline關鍵字），這時將得到該錯誤資訊。為避免該問題的發生，應該在相應的標頭檔案中用inline關鍵字標誌行內函數。

　　8．不正確的/SUBSYSTEM或/ENTRY設定也能導致LNK2001

到此這篇關於VC中LINK 2001 和 LINK 2009 的錯誤的解決方法的文章就介紹到這了,更多相關VC中常見LINK錯誤及解決方案內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！