天天看點

VC中LINK 2001 和 LINK 2009 的錯誤的解決

最近将兩個開源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的版本。