解決出現的LNK2005“符號已定義”錯誤(轉)

解決出現的LNK2005“符號已定義”錯誤(轉)[@more@]許多Visual C++的使用者都碰到過LNK2005:symbol already defined和LNK1169:one or more multiply defined symbols found這樣的連結錯誤，而且通常是在使用第三方庫時遇到的。對於這個問題，有的朋友可能不知其然，而有的朋友可能知其然卻不知其所以然，那麼本文就試圖為大家徹底解開關於它的種種疑惑。

大家都知道，從C/C++源程式到可執行檔案要經歷兩個階段:(1)編譯器將原始檔編譯成彙編程式碼，然後由彙編器(assembler)翻譯成機器指令 (再加上其它相關資訊)後輸出到一個個目標檔案(object file,VC的編譯器編譯出的目標檔案預設的字尾名是.obj)中；(2)連結器(linker)將一個個的目標檔案(或許還會有若干程式庫)連結在一起生成一個完整的可執行檔案。

編譯器編譯原始檔時會把原始檔的全域性符號(global symbol)分成強(strong)和弱(weak)兩類傳給彙編器，而隨後彙編器則將強弱資訊編碼並儲存在目標檔案的符號表中。那麼何謂強弱呢？編譯器認為函式與初始化了的全域性變數都是強符號，而未初始化的全域性變數則成了弱符號。比如有這麼個原始檔:

extern int errorno;
int buf[2] = {1,2};
int *p;

int main()
{
return 0;
}

其中main、buf是強符號，p是弱符號，而errorno則非強非弱，因為它只是個外部變數的使用宣告。

有了強弱符號的概念，我們就可以看看連結器是如何處理與選擇被多次定義過的全域性符號:

規則1: 不允許強符號被多次定義(即不同的目標檔案中不能有同名的強符號)；


規則2: 如果一個符號在某個目標檔案中是強符號，在其它檔案中都是弱符號，那麼選擇強符號；


規則3: 如果一個符號在所有目標檔案中都是弱符號，那麼選擇其中任意一個；

由上可知多個目標檔案不能重複定義同名的函式與初始化了的全域性變數，否則必然導致LNK2005和LNK1169兩種連結錯誤。可是，有的時候我們並沒有在自己的程式中發現這樣的重定義現象，卻也遇到了此種連結錯誤，這又是何解？嗯，問題稍微有點兒複雜，容我慢慢道來。

眾所周知，ANSI C/C++ 定義了相當多的標準函式，而它們又分佈在許多不同的目標檔案中，如果直接以目標檔案的形式提供給程式設計師使用的話，就需要他們確切地知道哪個函式存在於哪個目標檔案中，並且在連結時顯式地指定目標檔名才能成功地生成可執行檔案，顯然這是一個巨大的負擔。所以C語言提供了一種將多個目標檔案打包成一個檔案的機制，這就是靜態程式庫(static library)。開發者在連結時只需指定程式庫的檔名，連結器就會自動到程式庫中尋找那些應用程式確實用到的目標模組，並把(且只把)它們從庫中複製出來參與構建可執行檔案。幾乎所有的C/C++開發系統都會把標準函式打包成標準庫提供給開發者使用(有不這麼做的嗎？)。

程式庫為開發者帶來了方便，但同時也是某些混亂的根源。我們來看看連結器是如何解析(resolve)對程式庫的引用的。

在符號解析(symbol resolution)階段，連結器按照所有目標檔案和庫檔案出現在命令列中的順序從左至右依次掃描它們，在此期間它要維護若干個集合:(1)集合E是將被合併到一起組成可執行檔案的所有目標檔案集合；(2)集合U是未解析符號(unresolved symbols，比如已經被引用但是還未被定義的符號)的集合；(3)集合D是所有之前已被加入到E的目標檔案定義的符號集合。一開始，E、U、D都是空的。

(1): 對命令列中的每一個輸入檔案f，連結器確定它是目標檔案還是庫檔案，如果它是目標檔案，就把f加入到E，並把f中未解析的符號和已定義的符號分別加入到U、D集合中，然後處理下一個輸入檔案。

(2): 如果f是一個庫檔案，連結器會嘗試把U中的所有未解析符號與f中各目標模組定義的符號進行匹配。如果某個目標模組m定義了一個U中的未解析符號，那麼就把 m加入到E中，並把m中未解析的符號和已定義的符號分別加入到U、D集合中。不斷地對f中的所有目標模組重複這個過程直至到達一個不動點(fixed point)，此時U和D不再變化。而那些未加入到E中的f裡的目標模組就被簡單地丟棄，連結器繼續處理下一輸入檔案。

(3): 如果處理過程中往D加入一個已存在的符號，或者當掃描完所有輸入檔案時U非空，連結器報錯並停止動作。否則，它把E中的所有目標檔案合併在一起生成可執行檔案。

VC帶的編譯器名字叫cl.exe，它有這麼幾個與標準程式庫有關的選項: /ML、/MLd、/MT、/MTd、/MD、/MDd。這些選項告訴編譯器應用程式想使用什麼版本的C標準程式庫。/ML(預設選項)對應單執行緒靜態版的標準程式庫(libc.lib)；/MT對應多執行緒靜態版標準庫(libcmt.lib)，此時編譯器會自動定義_MT宏；/MD對應多執行緒DLL版 (匯入庫msvcrt.lib，DLL是msvcrt.dll)，編譯器自動定義_MT和_DLL兩個宏。後面加d的選項都會讓編譯器自動多定義一個 _DEBUG宏，表示要使用對應標準庫的除錯版，因此/MLd對應除錯版單執行緒靜態標準庫(libcd.lib)，/MTd對應除錯版多執行緒靜態標準庫 (libcmtd.lib)，/MDd對應除錯版多執行緒DLL標準庫(匯入庫msvcrtd.lib，DLL是msvcrtd.dll)。雖然我們的確在編譯時明白無誤地告訴了編譯器應用程式希望使用什麼版本的標準庫，可是當編譯器幹完了活，輪到連結器開工時它又如何得知一個個目標檔案到底在思念誰？為了傳遞相思，我們的編譯器就幹了點秘密的勾當。在cl編譯出的目標檔案中會有一個專門的區域(關心這個區域到底在檔案中什麼地方的朋友可以參考COFF和 PE檔案格式)存放一些指導連結器如何工作的資訊，其中有一種就叫預設庫(default library)，這些資訊指定了一個或多個庫檔名，告訴連結器在掃描的時候也把它們加入到輸入檔案列表中(當然順序位於在命令列中被指定的輸入檔案之後)。說到這裡，我們先來做個小實驗。寫個頂頂簡單的程式，然後儲存為main.c :

/* main.c */
int main() { return 0; }

　　用下面這個命令編譯main.c(什麼？你從不用命令列來編譯程式？這個......) :

cl /c main.c

/c 是告訴cl只編譯原始檔，不用連結。因為/ML是預設選項，所以上述命令也相當於: cl /c /ML main.c 。如果沒什麼問題的話(要出了問題才是活見鬼！當然除非你的環境變數沒有設定好，這時你應該去VC的bin目錄下找到vcvars32.bat檔案然後執行它。)，當前目錄下會出現一個main.obj檔案，這就是我們可愛的目標檔案。隨便用一個文字編輯器開啟它(是的，文字編輯器，大膽地去做別害怕)，搜尋"defaultlib"字串，通常你就會看到這樣的東西: "-defaultlib:LIBC -defaultlib:OLDNAMES"。啊哈，沒錯，這就
是儲存在目標檔案中的預設庫資訊。我們的目標檔案顯然指定了兩個預設庫，一個是單執行緒靜態版標準庫libc.lib(這與/ML選項相符)，另外一個是oldnames.lib(它是為了相容微軟以前的C/C++開發系統)。

VC的連結器是link.exe，因為main.obj儲存了預設庫資訊，所以可以用

link main.obj libc.lib

或者

link main.obj

來生成可執行檔案main.exe，這兩個命令是等價的。但是如果你用

link main.obj libcd.lib

的話，連結器會給出一個警告: "warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library"，因為你顯式指定的標準庫版本與目標檔案的預設值不一致。通常來說，應該保證連結器合併的所有目標檔案指定的預設標準庫版本一致，否則編譯器一定會給出上面的警告，而LNK2005和LNK1169連結錯誤則有時會出現有時不會。那麼這個有時到底是什麼時候？呵呵，彆著急，下面的一切正是為喜歡追根究底的你準備的。

建一個原始檔，就叫mylib.c，內容如下:

/* mylib.c */
#include

void foo()
{
printf("%s","I am from mylib! ");
}

用

cl /c /MLd mylib.c

命令編譯，注意/MLd選項是指定libcd.lib為預設標準庫。lib.exe是VC自帶的用於將目標檔案打包成程式庫的命令，所以我們可以用

lib /OUT:my.lib mylib.obj

將mylib.obj打包成庫，輸出的庫檔名是my.lib。接下來把main.c改成:

/* main.c */
void foo();

int main()
{
foo();
return 0;
}

用

cl /c main.c

編譯，然後用

link main.obj my.lib

進行連結。這個命令能夠成功地生成main.exe而不會產生LNK2005和LNK1169連結錯誤，你僅僅是得到了一條警告資訊:"warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library"。我們根據前文所述的掃描規則來分析一下連結器此時做了些啥。

一開始E、U、D都是空集，連結器首先掃描到main.obj，把它加入E集合，同時把未解析的foo加入U，把main加入D，而且因為 main.obj的預設標準庫是libc.lib，所以它被加入到當前輸入檔案列表的末尾。接著掃描my.lib，因為這是個庫，所以會拿當前U中的所有符號(當然現在就一個foo)與my.lib中的所有目標模組(當然也只有一個mylib.obj)依次匹配，看是否有模組定義了U中的符號。結果 mylib.obj確實定義了foo，於是它被加入到E，foo從U轉移到D，mylib.obj引用的printf加入到U，同樣地， mylib.obj指定的預設標準庫是libcd.lib，它也被加到當前輸入檔案列表的末尾(在libc.lib的後面)。不斷地在my.lib庫的各模組上進行迭代以匹配U中的符號，直到U、D都不再變化。很明顯，現在就已經到達了這麼一個不動點，所以接著掃描下一個輸入檔案，就是libc.lib。

連結器發現libc.lib裡的printf.obj裡定義有printf，於是printf從U移到D，而printf.obj被加入到E，它定義的所有符號加入到D，它裡頭的未解析符號加入到U。連結器還會把每個程式都要用到的一些初始化操作所在的目標模組(比如crt0.obj等)及它們所引用的模組 (比如malloc.obj、free.obj等)自動加入到E中，並更新U和D以反應這個變化。事實上，標準庫各目標模組裡的未解析符號都可以在庫內其它模組中找到定義，因此當連結器處理完libc.lib時，U一定是空的。最後處理libcd.lib，因為此時U已經為空，所以連結器會拋棄它裡面的所有目標模組從而結束掃描，然後合併E中的目標模組並輸出可執行檔案。

上文描述了雖然各目標模組指定了不同版本的預設標準庫但仍然連結成功的例子，接下來你將目睹因為這種不嚴謹而導致的悲慘失敗。

修改mylib.c成這個樣子:

#include

void foo()
{
// just a test , don't care memory leak
_malloc_dbg( 1, _NORMAL_BLOCK, __FILE__, __LINE__ );
}

其中_malloc_dbg不是ANSI C的標準庫函式，它是VC標準庫提供的malloc的除錯版，與相關函式配套能幫助開發者抓各種記憶體錯誤。使用它一定要定義_DEBUG宏，否則前處理器會把它自動轉為malloc。繼續用

cl /c /MLd mylib.c
lib /OUT:my.lib mylib.obj

編譯打包。當再次用

link main.obj my.lib

進行連結時，我們看到了什麼？天哪，一堆的LNK2005加上個貴為"fatal error"的LNK1169墊底，當然還少不了那個LNK4098。連結器是不是瘋了？不，你冤枉可憐的連結器了，我拍胸脯保證它可是一直在盡心盡責地照章辦事。

一開始E、U、D為空，連結器掃描main.obj，把它加入E，把foo加入U，把 main加入D，把libc.lib加入到當前輸入檔案列表的末尾。接著掃描my.lib，foo從U轉移到D，_malloc_dbg加入到U， libcd.lib加到當前輸入檔案列表的尾部。然後掃描libc.lib，這時會發現libc.lib裡任何一個目標模組都沒有定義 _malloc_dbg(它只在除錯版的標準庫中存在)，所以不會有任何一個模組因為_malloc_dbg而加入E，但是每個程式都要用到的初始化模組 (如crt0.obj等)及它們所引用的模組(比如malloc.obj、free.obj等)還是會自動加入到E中，同時U和D被更新以反應這個變化。當連結器處理完libc.lib時，U只剩_malloc_dbg這一個符號。最後處理libcd.lib，發現dbgheap.obj定義了 _malloc_dbg，於是dbgheap.obj加入到E，它裡頭的未解析符號加入U，它定義的所有其它符號也加入D，這時災難便來了。之前 malloc等符號已經在D中(隨著libc.lib裡的malloc.obj加入E而加入的)，而dbgheap.obj又定義了包括malloc在內的許多同名符號，這引發了重定義衝突，連結器只好中斷工作並報告錯誤。

現在我們該知道，連結器完全沒有責任，責任在我們自己的身上。是我們粗心地把預設標準庫版本不一致的目標檔案(main.obj)與程式庫 (my.lib)連結起來，導致了大災難。解決辦法很簡單，要麼用/MLd選項來重編譯main.c；要麼用/ML選項重編譯mylib.c。

在上述例子中，我們擁有庫my.lib的原始碼(mylib.c)，所以可以用不同的選項重新編譯這些原始碼並再次打包。可如果使用的是第三方的庫，它並沒有提供原始碼，那麼我們就只有改變自己程式的編譯選項來適應這些庫了。但是如何知道庫中目標模組指定的預設庫呢？其實VC提供的一個小工具便可以完成任務，這就是dumpbin.exe。執行下面這個命令

dumpbin /DIRECTIVES my.lib

　　然後在輸出中找那些"Linker Directives"引導的資訊，你一定會發現每一處這樣的資訊都會包含若干個類似"-defaultlib:XXXX"這樣的字串，其中XXXX便代表目標模組指定的預設庫名。

　　知道了第三方庫指定的預設標準庫，再用合適的選項編譯我們的應用程式，就可以避免LNK2005和LNK1169連結錯誤。喜歡IDE的朋友，你一樣可以到 "Project屬性" -> "C/C++" -> "程式碼生成(code generation)" -> "執行時庫(run-time library)" 項下設定應用程式的預設標準庫版本，這與命令列選項的效果是一樣的。