最近將兩個(gè)開源C++項(xiàng)目編譯成windows版本的時(shí)候遇到很多問題，關(guān)鍵是兩個(gè)項(xiàng)目經(jīng)過同事的修改之后，一個(gè)項(xiàng)目引用了另一個(gè)項(xiàng)目，兩個(gè)項(xiàng)目的頭文件中都有一些跨平臺的關(guān)于數(shù)據(jù)類型，以及一些通用函數(shù)的定義，所以導(dǎo)致有沖突，編譯的時(shí)候總是報(bào)錯(cuò)，報(bào)的最多的是“無法解析的外部符號”，經(jīng)過近3天的折騰總算都通過了，這里是一些總結(jié)。

首先，關(guān)于VC中的lib，與linux下的靜態(tài)庫是不同的，在VC中編譯動(dòng)態(tài)庫的時(shí)候會生成一個(gè)lib和一個(gè)對應(yīng)的dll，使用者在使用的時(shí)候需要包含頭文件以及連接到該lib，在發(fā)布最終程序的時(shí)候則需要將對應(yīng)的dll拷貝到發(fā)布目錄。當(dāng)然也可以使用LoadLibrary的方式在程序中動(dòng)態(tài)加載dll而不需要使用這個(gè)動(dòng)態(tài)庫生成的lib了。

如果是靜態(tài)庫，編譯之后只會生成一個(gè)lib文件，該lib文件非常大，可能有幾十M的大小，(而編譯動(dòng)態(tài)庫的時(shí)候生成的lib可能只有幾十KB或者幾百KB)在使用這個(gè)靜態(tài)庫的lib的時(shí)候，也需要指定頭文件，與對應(yīng)的lib庫文件，編譯成功之后就可以直接運(yùn)行，不需要拷貝額外的文件了。

另外如果A是靜態(tài)庫，B是靜態(tài)庫，并且B使用了A的接口，這個(gè)時(shí)候在編譯B的時(shí)候只需要指定A的頭文件就可以了，不需要指定A的庫文件。如果有一個(gè)項(xiàng)目C編譯成可執(zhí)行文件，C使用了B中的接口，這個(gè)時(shí)候在編譯C的時(shí)候，需要同時(shí)指定B的頭文件(如果該頭文件中又引用了A的頭文件那可能也要同時(shí)指定A的頭文件)，與B的lib庫文件，以及A的lib庫文件。 也就是說編譯C的時(shí)候要指定之前所有依賴的lib文件。

在windows中編譯動(dòng)態(tài)庫的時(shí)候，如果動(dòng)態(tài)庫中的函數(shù)需要給別人使用，那么這些函數(shù)或者類則需要被導(dǎo)出，具體如下，假設(shè)庫的頭文件為A.h：

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

如果在項(xiàng)目B中使用A庫，那么項(xiàng)目B在引用A.h的時(shí)候，由于項(xiàng)目B沒有定義LIB_A這個(gè)宏，所以實(shí)際上使用的是#define DLLEXP __declspec(dllimport)這個(gè)定義，也就是說在B項(xiàng)目中，這個(gè)ExportClass類的聲明變成導(dǎo)入了，表示該類是從外部庫導(dǎo)入的類。 而在項(xiàng)目A中由于定義了LIB_A這個(gè)項(xiàng)目特有的宏，所以使用的是#define DLLEXP __declspec(dllexport)這個(gè)定義，說明需要編譯成導(dǎo)出給別人用的類。

如果是C語言的庫給C++使用或者C++的庫封裝給C使用則除了要添加__declspec(dllexport)導(dǎo)出聲明之外，還需要添加 external "C" 的聲明，該聲明主要告訴編譯器，編譯的時(shí)候生成的函數(shù)的符號表按照C的規(guī)則來生成。 因?yàn)镃編譯器與C++編譯器生成符號表的時(shí)候規(guī)則是不一樣的。

那么編譯的時(shí)候報(bào)告LINK錯(cuò)誤，無法解析的外部符號，一般是下面幾種原因造成的：

1. 最常見的情況是要么沒有指定引用庫的路徑，或者沒有指定所以依賴的庫文件名字。
2. 如果正確指定了lib庫路徑，以及l(fā)ib庫名，那檢查一下該lib中是否有該符號的實(shí)現(xiàn)，也就是說頭文件中聲明了該符號，但是該庫文件中卻沒有具體的實(shí)現(xiàn)。
3. 如果庫文件中確實(shí)實(shí)現(xiàn)了符號的定義，那么檢查一下lib庫的版本是否與正確(32位或者64位)。還有如果報(bào)告的是某一個(gè)函數(shù)無法解析，則要對比一下該函數(shù)在庫中的實(shí)現(xiàn)與在頭文件中的聲明是否一致(特別是函數(shù)的參數(shù)個(gè)數(shù)與參數(shù)類型是否完全一致)。
4. 有一種情況就是在編譯lib的時(shí)候，該lib是動(dòng)態(tài)庫，但是沒有添加導(dǎo)出聲明，導(dǎo)致該庫中的函數(shù)并不對外導(dǎo)出(靜態(tài)庫不需要導(dǎo)出聲明，加了反而會有問題)，那么使用者在鏈接的時(shí)候也會報(bào)無法解析的符號。
5. 還有一種非常隱蔽的情況，這也是我遇到的情況，在項(xiàng)目A中將一些基本的數(shù)據(jù)類型做了typedef，例如類似下面的定義：

typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;

然后A項(xiàng)目的導(dǎo)出函數(shù) FUNC(uint8_t); 使用了該uint8_t，但是在B項(xiàng)目中對上述的 uint8_t 又做了另外一套定義 (如果A和B是兩個(gè)開源項(xiàng)目則很有可能出現(xiàn)這種沖突)，如下：

typedef unsigned __int8 uint8_t;

那么在B中使用A的時(shí)候，使用的uint8_t是B的定義，實(shí)際上函數(shù)的聲明變成了 FUNC(unsigned __int8) 但是在A的lib庫文件的實(shí)現(xiàn)里面使用的是FUNC(unsigned char)也就是說該函數(shù)FUNC的聲明與定義并不匹配，那么當(dāng)然也會報(bào)告找不到符號了，這種情況一般是在兩個(gè)開源項(xiàng)目混合使用的時(shí)候就會出現(xiàn)沖突。

6. 編譯靜態(tài)庫的時(shí)候，如果靜態(tài)庫B引用了靜態(tài)庫A中的內(nèi)容，此時(shí)在B的項(xiàng)目里面都不需要指定A的庫路徑，只需要指定A的相關(guān)頭文件，就可以編譯通過，如果里面有什么問題，那么會在最終使用B的項(xiàng)目的時(shí)候，鏈接的時(shí)候報(bào)出來。例如C項(xiàng)目使用了B，那么在編譯C的時(shí)候需要同時(shí)添加A和B兩個(gè)庫，如果之前B使用A的過程中有問題的話，那么在編譯C的時(shí)候就會報(bào)告LINK錯(cuò)誤，而不是在編譯B的時(shí)候報(bào)告(除非是語法錯(cuò)誤)。

7. 如果項(xiàng)目C使用了B庫與A庫，但是B與A是有依賴關(guān)系的，那么在C的工程設(shè)置中，也要指定B和A的先后關(guān)系，否則也可能會報(bào)錯(cuò)。

8. 如果在連接項(xiàng)目的時(shí)候報(bào)告下面的錯(cuò)誤：

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

這種錯(cuò)誤一般是在Release版本的項(xiàng)目中使用了Debug的庫，但是有時(shí)候明明看到我們編譯的庫都是Release版本的，使用那個(gè)庫的時(shí)候卻還是報(bào)告這個(gè)問題，這個(gè)現(xiàn)象可能是，編譯那個(gè)庫的時(shí)候，雖然選擇的是Release方式編譯，但是在項(xiàng)目的宏定義中卻定義了_DEBUG宏，導(dǎo)致該還是會被認(rèn)為是Debug的版本。

VC中常見LINK錯(cuò)誤及解決方案

. Windows子系統(tǒng)設(shè)置錯(cuò)誤, 提示:
libcmtd.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
Windows項(xiàng)目要使用Windows子系統(tǒng), 而不是Console, 可以這樣設(shè)置:

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

2. Console子系統(tǒng)設(shè)置錯(cuò)誤, 提示:
LIBCD.lib(wincrt0.obj) : error LNK2001: unresolved external symbol _WinMain@16

控制臺項(xiàng)目要使用Console子系統(tǒng), 而不是Windows, 設(shè)置:

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

3. 程序入口設(shè)置錯(cuò)誤, 提示:
msvcrtd.lib(crtexew.obj) : error LNK2001: unresolved external symbol _WinMain@16

通常, MFC項(xiàng)目的程序入口函數(shù)是WinMain, 如果編譯項(xiàng)目的Unicode版本, 程序入口必須改為wWinMainCRTStartup, 所以需要重新設(shè)置程序入口:

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

4. 線程運(yùn)行時(shí)庫設(shè)置錯(cuò)誤, 提示:
nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __beginthreadex
nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __endthreadex

這是因?yàn)镸FC要使用多線程時(shí)庫, 需要更改設(shè)置:

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

其中,
Single-Threaded 單線程靜態(tài)鏈接庫(release版本)
Multithreaded 多線程靜態(tài)鏈接庫(release版本)
multithreaded DLL 多線程動(dòng)態(tài)鏈接庫(release版本)
Debug Single-Threaded 單線程靜態(tài)鏈接庫(debug版本)
Debug Multithreaded 多線程靜態(tài)鏈接庫(debug版本)
Debug Multithreaded DLL 多線程動(dòng)態(tài)鏈接庫(debug版本)

單線程: 不需要多線程調(diào)用時(shí), 多用在DOS環(huán)境下
多線程: 可以并發(fā)運(yùn)行
靜態(tài)庫: 直接將庫與程序Link, 可以脫離MFC庫運(yùn)行
動(dòng)態(tài)庫: 需要相應(yīng)的DLL動(dòng)態(tài)庫, 程序才能運(yùn)行
release版本: 正式發(fā)布時(shí)使用
debug版本: 調(diào)試階段使用

初學(xué)者在學(xué)習(xí)VC++的過程中，遇到的LNK2001錯(cuò)誤的錯(cuò)誤消息主要為：

　　unresolved external symbol “symbol”（不確定的外部“符號”）。

　　如果連接程序不能在所有的庫和目標(biāo)文件內(nèi)找到所引用的函數(shù)、變量或標(biāo)簽，將產(chǎn)生此錯(cuò)誤消息。一般來說，發(fā)生錯(cuò)誤的原因有兩個(gè)：一是所引用的函數(shù)、變量不存在、拼寫不正確或者使用錯(cuò)誤；其次可能使用了不同版本的連接庫。

　　以下是可能產(chǎn)生LNK2001錯(cuò)誤的原因：

　　一．由于編碼錯(cuò)誤導(dǎo)致的LNK2001

　　1．不相匹配的程序代碼或模塊定義(.DEF)文件能導(dǎo)致LNK2001。例如, 如果在C++源文件內(nèi)聲明了一變量“var1”，卻試圖在另一文件內(nèi)以變量“VAR1”訪問該變量,將發(fā)生該錯(cuò)誤。

　　2．如果使用的內(nèi)聯(lián)函數(shù)是在.CPP文件內(nèi)定義的，而不是在頭文件內(nèi)定義將導(dǎo)致LNK2001錯(cuò)誤。

　　3．調(diào)用函數(shù)時(shí)如果所用的參數(shù)類型同函數(shù)聲明時(shí)的類型不符將會產(chǎn)生LNK2001。

　　4．試圖從基類的構(gòu)造函數(shù)或析構(gòu)函數(shù)中調(diào)用虛擬函數(shù)時(shí)將會導(dǎo)致LNK2001。

　　5．要注意函數(shù)和變量的可公用性，只有全局變量、函數(shù)是可公用的。靜態(tài)函數(shù)和靜態(tài)變量具有相同的使用范圍限制。當(dāng)試圖從文件外部訪問任何沒有在該文件內(nèi)聲明的靜態(tài)變量時(shí)將導(dǎo)致編譯錯(cuò)誤或LNK2001。

　　函數(shù)內(nèi)聲明的變量(局部變量) 只能在該函數(shù)的范圍內(nèi)使用。

C++ 的全局常量只有靜態(tài)連接性能。這不同于C，如果試圖在C++的多個(gè)文件內(nèi)使用全局變量也會產(chǎn)生LNK2001錯(cuò)誤。一種解決的方法是需要時(shí)在頭文件中加入該常量的初始化代碼，并在.CPP文件中包含該頭文件；另一種方法是使用時(shí)給該變量賦以常數(shù)。

　　二．由于編譯和鏈接的設(shè)置而造成的LNK2001

　　1．如果編譯時(shí)使用的是/NOD(/NODEFAULTLIB)選項(xiàng)，程序所需要的運(yùn)行庫和MFC庫在連接時(shí)由編譯器寫入目標(biāo)文件模塊， 但除非在文件中明確包含這些庫名，否則這些庫不會被鏈接進(jìn)工程文件。在這種情況下使用/NOD將導(dǎo)致錯(cuò)誤LNK2001。

　　2．如果沒有為wWinMainCRTStartup設(shè)定程序入口，在使用Unicode和MFC時(shí)將得到“unresolved external on _WinMain@16”的LNK2001錯(cuò)誤信息。

　　3．使用/MD選項(xiàng)編譯時(shí),既然所有的運(yùn)行庫都被保留在動(dòng)態(tài)鏈接庫之內(nèi)，源文件中對“func”的引用，在目標(biāo)文件里即對“__imp__func” 的引用。如果試圖使用靜態(tài)庫LIBC.LIB或LIBCMT.LIB進(jìn)行連接，將在__imp__func上發(fā)生LNK2001；如果不使用/MD選項(xiàng)編
　　譯，在使用MSVCxx.LIB連接時(shí)也會發(fā)生LNK2001。

　　4．使用/ML選項(xiàng)編譯時(shí)，如用LIBCMT.LIB鏈接會在_errno上發(fā)生LNK2001。

　　5．當(dāng)編譯調(diào)試版的應(yīng)用程序時(shí)，如果采用發(fā)行版模態(tài)庫進(jìn)行連接也會產(chǎn)生LNK2001；同樣，使用調(diào)試版模態(tài)庫連接發(fā)行版應(yīng)用程序時(shí)也會產(chǎn)生相同的問題。

　　6．不同版本的庫和編譯器的混合使用也能產(chǎn)生問題，因?yàn)樾掳娴膸炖锟赡馨缦鹊陌姹緵]有的符號和說明。

　　編程時(shí)打開了函數(shù)內(nèi)聯(lián)（/Ob1或/Ob2)，但是在描述該函數(shù)的相應(yīng)頭文件里卻關(guān)閉了函數(shù)內(nèi)聯(lián)（沒有inline關(guān)鍵字），這時(shí)將得到該錯(cuò)誤信息。為避免該問題的發(fā)生，應(yīng)該在相應(yīng)的頭文件中用inline關(guān)鍵字標(biāo)志內(nèi)聯(lián)函數(shù)。

　　8．不正確的/SUBSYSTEM或/ENTRY設(shè)置也能導(dǎo)致LNK2001

到此這篇關(guān)于VC中LINK 2001 和 LINK 2009 的錯(cuò)誤的解決方法的文章就介紹到這了,更多相關(guān)VC中常見LINK錯(cuò)誤及解決方案內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！