爲什麼會出現LNK2005"符號已定義"的鏈接錯誤?
<script language="javascript" type="text/javascript">document.title="爲什麼會出現LNK2005"符號已定義"的鏈接錯誤? - "+document.title</script>
許多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則非強非弱，因爲它只是個外部變量的使用聲明。
有了強弱符號的概念，鏈接器(Unix平臺)就會按如下規則(參考[1]，p549~p550)處理與選擇被多次定義的全局符號:
規則1: 不允許強符號被多次定義(即不同的目標文件中不能有同名的強符號)；
規則2: 如果一個符號在某個目標文件中是強符號，在其它文件中都是弱符號，那麼選擇強符號；
規則3: 如果一個符號在所有目標文件中都是弱符號，那麼選擇其中任意一個；
雖然上述3條針對的是Unix平臺的鏈接器，但據作者試驗，至少VC6.0的linker也遵守這些規則。由此可知多個目標文件不能重複定義同名的函數與初始化了的全局變量，否則必然導致LNK2005和LNK1169兩種鏈接錯誤。可是，有的時候我們並沒有在自己的程序中發現這樣的重定義現象，卻也遇到了此種鏈接錯誤，這又是何解？嗯，問題稍微有點兒複雜，容我慢慢道來。
衆所周知，ANSI C/C++ 定義了相當多的標準函數，而它們又分佈在許多不同的目標文件中，如果直接以目標文件的形式提供給程序員使用的話，就需要他們確切地知道哪個函數存在於哪個目標文件中，並且在鏈接時顯式地指定目標文件名才能成功地生成可執行文件，顯然這是一個巨大的負擔。所以C語言提供了一種將多個目標文件打包成一個文件的機制，這就是靜態程序庫(static library)。開發者在鏈接時只需指定程序庫的文件名，鏈接器就會自動到程序庫中尋找那些應用程序確實用到的目標模塊，並把(且只把)它們從庫中拷貝出來參與構建可執行文件。幾乎所有的C/C++開發系統都會把標準函數打包成標準庫提供給開發者使用(有不這麼做的嗎？)。
程序庫爲開發者帶來了方便，但同時也是某些混亂的根源。我們來看看鏈接器(Unix平臺)是如何解析(resolve)對程序庫的引用的(參考[1]，p556)。
在符號解析(symbol resolution)階段，鏈接器按照所有目標文件和庫文件出現在命令行中的順序從左至右依次掃描它們，在此期間它要維護若干個集合:(1)集合E是將被合併到一起組成可執行文件的所有目標文件集合；(2)集合D是所有之前已被加入E的目標文件定義的符號集合；(3)集合U是未解析符號(unresolved symbols，即那些被E中目標文件引用過但在D中還不存在的符號)的集合。一開始，E、D、U都是空的。
(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): 當掃描完所有輸入文件時如果U非空或者有同名的符號被多次加入D，鏈接器報告錯誤信息並退出。否則，它把E中的所有目標文件合併在一起生成可執行文件。
上述規則針對的是Unix平臺鏈接器，而VC(至少VC6.0)linker則有相當的不同: 它首先依次處理命令行中出現的所有目標文件，然後依照順序不停地掃描所有的庫文件，直至U爲空或者某遍(從頭到尾依次把所有的庫文件掃描完稱爲一遍)掃描過程中U、D無任何變化時結束掃描，此刻再根據U是否爲空以及是否有同名符號重複加入D來決定是出錯退出還是生成可執行文件。很明顯Unix鏈接器對輸入文件在命令行中出現的順序十分敏感，而VC的算法則可最大限度地減少文件順序對鏈接的影響。作者不清楚Unix下新的開發工具是否已經改進了相應的做法，歡迎有實踐經驗的朋友補充這方面的信息(補充於2005年10月10日: 經試驗，使用gcc 3.2.3的MinGW 3.1.0的鏈接器表現與參考[1]描述的一致)。
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++開發系統，基本不用了，爲了簡化討論可以忽略它)。另外，如果在源程序中用了
/* xxxx代表實際的庫文件名 */
#pragma comment(lib,"xxxx")
編譯指示命令(compiler directive)指定要鏈接的庫，那麼這個信息也會被保存到目標文件的缺省庫信息項中，且位於缺省標準庫之前。如果有多個這樣的命令，那麼對應庫名在目標文件中出現的順序與它們在源程序中出現的順序完全一致(且都在缺省標準庫之前)。
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 <stdio.h>
void foo(void)
{
printf("%s","I am from mylib!/n");
}
用
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(void);
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"。我們根據前文所述的掃描規則來分析一下鏈接器此時做了些啥(加一個/VERBOSE選項就可以看到詳盡的鏈接過程，但要注意，幾乎所有的C編譯器都會在符號前加一個下劃線後再輸出，所以在目標文件和鏈接輸出信息中看到的符號名都比在源程序中見到的多出一個'_'，此點不可不察。)。
一開始E、U、D都是空集。鏈接器首先掃描main.obj，把它的默認標準庫libc.lib加入到輸入文件列表末尾，它自己加入E集合，同時未解析的foo加入U，main加入D。接着掃描my.lib，因爲這是個庫，所以會拿當前U中的所有符號(當然現在就一個foo)與my.lib中的所有目標模塊(當然也只有一個mylib.obj)依次匹配，看是否有模塊定義了U中的符號。結果mylib.obj確實定義了foo，於是它加入到E，foo從U轉移到D，未解析的printf加入到U，指定的默認標準庫libcd.lib也加到輸入文件列表末尾(在libc.lib之後)。不斷地在my.lib庫的各模塊上進行迭代以匹配U中的符號，直到U、D都不再變化。很明顯，現在就已經到達了這麼一個不動點，所以接着掃描下一個輸入文件，就是libc.lib。鏈接器發現libc.lib裏的printf.obj裏定義有printf，於是printf從U移到D，printf.obj加入到E，它定義的所有符號加入到D，它裏頭的未解析符號加入到U。如果鏈接時沒有指定/ENTRY(程序入口點選項)，那麼鏈接器默認的入口點就是函數mainCRTStartup(GUI程序的默認入口點則是WinMainCRTStartup)，它在crt0.obj中被定義，所以crt0.obj及它直接或間接引用的模塊(比如malloc.obj、free.obj等)都被加入到E中，這些目標模塊指定的默認庫(只crt0init.obj指定了kernel32.lib)加到輸入文件列表末尾，同時更新U和D。不斷匹配libc.lib中各模塊直至到達不動點，然後處理libcd.lib，但是它裏面的所有目標模塊都沒有定義U中的任何一個符號，所以鏈接器略過它進入到最後一個輸入文件kernel32.lib。事實上，U中已有和將要加入的未解析符號都可以在其中找到定義，那麼當處理完kernel32.lib時，U必然爲空，於是鏈接器合併E中的所有模塊生成可執行文件。
上文描述了雖然各目標模塊指定了不同版本的缺省標準庫但仍然鏈接成功的例子，接下來你將目睹因爲這種不嚴謹而導致的悲慘失敗。
修改mylib.c成這個樣子:
#include <crtdbg.h>
void foo(void)
{
// 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，把libc.lib加到輸入文件列表末尾，把main.obj加進E，把foo加進U，把main加進D。接着掃描my.lib，於是mylib.obj加入E，libcd.lib加到輸入文件列表末尾，foo從U轉移到D，_malloc_dbg加進U。然後掃描libc.lib，這時會發現libc.lib裏任何一個目標模塊都沒有定義_malloc_dbg(它只在調試版的標準庫中存在)，所以不會有任何一個模塊因爲_malloc_dbg而加入E。但因爲libc.lib中的crt0.obj定義了默認入口點函數mainCRTStartup，所以crt0.obj及它直接或間接引用的模塊(比如malloc.obj、free.obj等)都被加入到E中，這些目標模塊指定的默認庫(只crt0init.obj指定了kernel32.lib)加到輸入文件列表末尾，同時更新U和D。不斷匹配libc.lib中各模塊直至到達不動點後再處理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；再或者乾脆在鏈接時用/NODEFAULTLIB:XXX選項忽略默認庫XXX，但這種方法非常不保險(想想爲什麼？)，所以不推薦。
在上述例子中，我們擁有庫my.lib的源代碼(mylib.c)，所以可以用不同的選項重新編譯這些源代碼並再次打包。可如果使用的是第三方的庫，它並沒有提供源代碼，那麼我們就只有改變自己程序的編譯選項來適應這些庫了。但是如何知道庫中目標模塊指定的默認庫呢？其實VC提供的一個小工具便可以完成任務，這就是dumpbin.exe。運行下面這個命令
dumpbin /DIRECTIVES my.lib
然後在輸出中找那些"Linker Directives"引導的信息，你一定會發現每一處這樣的信息都會包含若干個類似"-defaultlib:XXXX"這樣的字符串，其中XXXX便代表目標模塊指定的缺省庫名(注意，如果在編譯時指定了/Zl選項，那麼目標模塊中將不會有defaultlib信息)。
知道了第三方庫指定的默認標準庫，再用合適的選項編譯我們的應用程序，就可以避免LNK2005和LNK1169鏈接錯誤。喜歡IDE的朋友，你一樣可以到 "Project屬性" -> "C/C++" -> "代碼生成(code generation)" -> "運行時庫(run-time library)" 項下設置應用程序的默認標準庫版本，這與命令行選項的效果是一樣的。
參考資料:
[1] 《Computer Systems: A Programmer's Perspective》
著: Randal E. Bryant, David R. O'Hallaron
電子工業出版社，2004
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=493238
<script type="text/javascript">document.write("
");</script>