大家都知道，從C/C++源程序到可執(zhí)行文件要經(jīng)歷兩個階段:(1)編譯器將源文件編譯成匯編代碼，然后由匯編器(assembler)翻譯成機(jī)器指令(再加上其它相關(guān)信息)后輸出到一個個目標(biāo)文件(object file,VC的編譯器編譯出的目標(biāo)文件默認(rèn)的后綴名是.obj)中；(2)鏈接器(linker)將一個個的目標(biāo)文件(或許還會有若干程序庫)鏈接在一起生成一個完整的可執(zhí)行文件。

    編譯器編譯源文件時會把源文件的全局符號(global symbol)分成強(qiáng)(strong)和弱(weak)兩類傳給匯編器，而隨后匯編器則將強(qiáng)弱信息編碼并保存在目標(biāo)文件的符號表中。那么何謂強(qiáng)弱呢？編譯器認(rèn)為函數(shù)與初始化了的全局變量都是強(qiáng)符號，而未初始化的全局變量則成了弱符號。比如有這么個源文件:

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

int main()
{
   return 0;
}

其中main、buf是強(qiáng)符號，p是弱符號，而errorno則非強(qiáng)非弱，因為它只是個外部變量的使用聲明。

    有了強(qiáng)弱符號的概念，我們就可以看看鏈接器是如何處理與選擇被多次定義過的全局符號:

規(guī)則1: 不允許強(qiáng)符號被多次定義(即不同的目標(biāo)文件中不能有同名的強(qiáng)符號)；

    由上可知多個目標(biāo)文件不能重復(fù)定義同名的函數(shù)與初始化了的全局變量，否則必然導(dǎo)致LNK2005和LNK1169兩種鏈接錯誤?？墒?，有的時候我們并沒有在自己的程序中發(fā)現(xiàn)這樣的重定義現(xiàn)象，卻也遇到了此種鏈接錯誤，這又是何解？嗯，問題稍微有點兒復(fù)雜，容我慢慢道來。

    眾所周知，ANSI C/C++ 定義了相當(dāng)多的標(biāo)準(zhǔn)函數(shù)，而它們又分布在許多不同的目標(biāo)文件中，如果直接以目標(biāo)文件的形式提供給程序員使用的話，就需要他們確切地知道哪個函數(shù)存在于哪個目標(biāo)文件中，并且在鏈接時顯式地指定目標(biāo)文件名才能成功地生成可執(zhí)行文件，顯然這是一個巨大的負(fù)擔(dān)。所以C語言提供了一種將多個目標(biāo)文件打包成一個文件的機(jī)制，這就是靜態(tài)程序庫(static library)。開發(fā)者在鏈接時只需指定程序庫的文件名，鏈接器就會自動到程序庫中尋找那些應(yīng)用程序確實用到的目標(biāo)模塊，并把(且只把)它們從庫中拷貝出來參與構(gòu)建可執(zhí)行文件。幾乎所有的C/C++開發(fā)系統(tǒng)都會把標(biāo)準(zhǔn)函數(shù)打包成標(biāo)準(zhǔn)庫提供給開發(fā)者使用(有不這么做的嗎？)。

    程序庫為開發(fā)者帶來了方便，但同時也是某些混亂的根源。我們來看看鏈接器是如何解析(resolve)對程序庫的引用的。
   
    在符號解析(symbol resolution)階段，鏈接器按照所有目標(biāo)文件和庫文件出現(xiàn)在命令行中的順序從左至右依次掃描它們，在此期間它要維護(hù)若干個集合:(1)集合E是將被合并到一起組成可執(zhí)行文件的所有目標(biāo)文件集合；(2)集合U是未解析符號(unresolved symbols，比如已經(jīng)被引用但是還未被定義的符號)的集合；(3)集合D是所有之前已被加入到E的目標(biāo)文件定義的符號集合。一開始，E、U、D都是空的。

(1): 對命令行中的每一個輸入文件f，鏈接器確定它是目標(biāo)文件還是庫文件，如果它是目標(biāo)文件，就把f加入到E，并把f中未解析的符號和已定義的符號分別加入到U、D集合中，然后處理下一個輸入文件。

(2): 如果f是一個庫文件，鏈接器會嘗試把U中的所有未解析符號與f中各目標(biāo)模塊定義的符號進(jìn)行匹配。如果某個目標(biāo)模塊m定義了一個U中的未解析符號，那么就把m加入到E中，并把m中未解析的符號和已定義的符號分別加入到U、D集合中。不斷地對f中的所有目標(biāo)模塊重復(fù)這個過程直至到達(dá)一個不動點(fixed point)，此時U和D不再變化。而那些未加入到E中的f里的目標(biāo)模塊就被簡單地丟棄，鏈接器繼續(xù)處理下一輸入文件。

(3): 如果處理過程中往D加入一個已存在的符號，或者當(dāng)掃描完所有輸入文件時U非空，鏈接器報錯并停止動作。否則，它把E中的所有目標(biāo)文件合并在一起生成可執(zhí)行文件。

    VC帶的編譯器名字叫cl.exe，它有這么幾個與標(biāo)準(zhǔn)程序庫有關(guān)的選項: /ML、/MLd、/MT、/MTd、/MD、/MDd。這些選項告訴編譯器應(yīng)用程序想使用什么版本的C標(biāo)準(zhǔn)程序庫。/ML(缺省選項)對應(yīng)單線程靜態(tài)版的標(biāo)準(zhǔn)程序庫(libc.lib)；/MT對應(yīng)多線程靜態(tài)版標(biāo)準(zhǔn)庫(libcmt.lib)，此時編譯器會自動定義_MT宏；/MD對應(yīng)多線程DLL版(導(dǎo)入庫msvcrt.lib，DLL是msvcrt.dll)，編譯器自動定義_MT和_DLL兩個宏。后面加d的選項都會讓編譯器自動多定義一個_DEBUG宏，表示要使用對應(yīng)標(biāo)準(zhǔn)庫的調(diào)試版，因此/MLd對應(yīng)調(diào)試版單線程靜態(tài)標(biāo)準(zhǔn)庫(libcd.lib)，/MTd對應(yīng)調(diào)試版多線程靜態(tài)標(biāo)準(zhǔn)庫(libcmtd.lib)，/MDd對應(yīng)調(diào)試版多線程DLL標(biāo)準(zhǔn)庫(導(dǎo)入庫msvcrtd.lib，DLL是msvcrtd.dll)。雖然我們的確在編譯時明白無誤地告訴了編譯器應(yīng)用程序希望使用什么版本的標(biāo)準(zhǔn)庫，可是當(dāng)編譯器干完了活，輪到鏈接器開工時它又如何得知一個個目標(biāo)文件到底在思念誰？為了傳遞相思，我們的編譯器就干了點秘密的勾當(dāng)。在cl編譯出的目標(biāo)文件中會有一個專門的區(qū)域(關(guān)心這個區(qū)域到底在文件中什么地方的朋友可以參考COFF和PE文件格式)存放一些指導(dǎo)鏈接器如何工作的信息，其中有一種就叫缺省庫(default library)，這些信息指定了一個或多個庫文件名，告訴鏈接器在掃描的時候也把它們加入到輸入文件列表中(當(dāng)然順序位于在命令行中被指定的輸入文件之后)。說到這里，我們先來做個小實驗。寫個頂頂簡單的程序，然后保存為main.c :

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

用下面這個命令編譯main.c(什么？你從不用命令行來編譯程序？這個......) :

cl /c main.c

/c是告訴cl只編譯源文件，不用鏈接。因為/ML是缺省選項，所以上述命令也相當(dāng)于: cl /c /ML main.c 。如果沒什么問題的話(要出了問題才是活見鬼！當(dāng)然除非你的環(huán)境變量沒有設(shè)置好，這時你應(yīng)該去VC的bin目錄下找到vcvars32.bat文件然后運行它。)，當(dāng)前目錄下會出現(xiàn)一個main.obj文件，這就是我們可愛的目標(biāo)文件。隨便用一個文本編輯器打開它(是的，文本編輯器，大膽地去做別害怕)，搜索"defaultlib"字符串，通常你就會看到這樣的東西: "-defaultlib:LIBC -defaultlib:OLDNAMES"。啊哈，沒錯，這就
是保存在目標(biāo)文件中的缺省庫信息。我們的目標(biāo)文件顯然指定了兩個缺省庫，一個是單線程靜態(tài)版標(biāo)準(zhǔn)庫libc.lib(這與/ML選項相符)，另外一個是oldnames.lib(它是為了兼容微軟以前的C/C++開發(fā)系統(tǒng))。

    VC的鏈接器是link.exe，因為main.obj保存了缺省庫信息，所以可以用

link main.obj libc.lib

或者

link main.obj

來生成可執(zhí)行文件main.exe，這兩個命令是等價的。但是如果你用

link main.obj libcd.lib

的話，鏈接器會給出一個警告: "warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library"，因為你顯式指定的標(biāo)準(zhǔn)庫版本與目標(biāo)文件的缺省值不一致。通常來說，應(yīng)該保證鏈接器合并的所有目標(biāo)文件指定的缺省標(biāo)準(zhǔn)庫版本一致，否則編譯器一定會給出上面的警告，而LNK2005和LNK1169鏈接錯誤則有時會出現(xiàn)有時不會。那么這個有時到底是什么時候？呵呵，別著急，下面的一切正是為喜歡追根究底的你準(zhǔn)備的。

    建一個源文件，就叫mylib.c，內(nèi)容如下:

/* mylib.c */
#include <stdio.h>

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

用

cl /c /MLd mylib.c

命令編譯，注意/MLd選項是指定libcd.lib為默認(rèn)標(biāo)準(zhǔn)庫。lib.exe是VC自帶的用于將目標(biāo)文件打包成程序庫的命令，所以我們可以用

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

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

    一開始E、U、D都是空集，鏈接器首先掃描到main.obj，把它加入E集合，同時把未解析的foo加入U，把main加入D，而且因為main.obj的默認(rèn)標(biāo)準(zhǔn)庫是libc.lib，所以它被加入到當(dāng)前輸入文件列表的末尾。接著掃描my.lib，因為這是個庫，所以會拿當(dāng)前U中的所有符號(當(dāng)然現(xiàn)在就一個foo)與my.lib中的所有目標(biāo)模塊(當(dāng)然也只有一個mylib.obj)依次匹配，看是否有模塊定義了U中的符號。結(jié)果mylib.obj確實定義了foo，于是它被加入到E，foo從U轉(zhuǎn)移到D，mylib.obj引用的printf加入到U，同樣地，mylib.obj指定的默認(rèn)標(biāo)準(zhǔn)庫是libcd.lib，它也被加到當(dāng)前輸入文件列表的末尾(在libc.lib的后面)。不斷地在my.lib庫的各模塊上進(jìn)行迭代以匹配U中的符號，直到U、D都不再變化。很明顯，現(xiàn)在就已經(jīng)到達(dá)了這么一個不動點，所以接著掃描下一個輸入文件，就是libc.lib。鏈接器發(fā)現(xiàn)libc.lib里的printf.obj里定義有printf，于是printf從U移到D，而printf.obj被加入到E，它定義的所有符號加入到D，它里頭的未解析符號加入到U。鏈接器還會把每個程序都要用到的一些初始化操作所在的目標(biāo)模塊(比如crt0.obj等)及它們所引用的模塊(比如malloc.obj、free.obj等)自動加入到E中，并更新U和D以反應(yīng)這個變化。事實上，標(biāo)準(zhǔn)庫各目標(biāo)模塊里的未解析符號都可以在庫內(nèi)其它模塊中找到定義，因此當(dāng)鏈接器處理完libc.lib時，U一定是空的。最后處理libcd.lib，因為此時U已經(jīng)為空，所以鏈接器會拋棄它里面的所有目標(biāo)模塊從而結(jié)束掃描，然后合并E中的目標(biāo)模塊并輸出可執(zhí)行文件。

    上文描述了雖然各目標(biāo)模塊指定了不同版本的缺省標(biāo)準(zhǔn)庫但仍然鏈接成功的例子，接下來你將目睹因為這種不嚴(yán)謹(jǐn)而導(dǎo)致的悲慘失敗。

    修改mylib.c成這個樣子:

#include <crtdbg.h>

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

其中_malloc_dbg不是ANSI C的標(biāo)準(zhǔn)庫函數(shù)，它是VC標(biāo)準(zhǔn)庫提供的malloc的調(diào)試版，與相關(guān)函數(shù)配套能幫助開發(fā)者抓各種內(nèi)存錯誤。使用它一定要定義_DEBUG宏，否則預(yù)處理器會把它自動轉(zhuǎn)為malloc。繼續(xù)用

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

編譯打包。當(dāng)再次用

link main.obj my.lib

進(jìn)行鏈接時，我們看到了什么？天哪，一堆的LNK2005加上個貴為"fatal error"的LNK1169墊底，當(dāng)然還少不了那個LNK4098。鏈接器是不是瘋了？不，你冤枉可憐的鏈接器了，我拍胸脯保證它可是一直在盡心盡責(zé)地照章辦事。

    一開始E、U、D為空，鏈接器掃描main.obj，把它加入E，把foo加入U，把main加入D，把libc.lib加入到當(dāng)前輸入文件列表的末尾。接著掃描my.lib，foo從U轉(zhuǎn)移到D，_malloc_dbg加入到U，libcd.lib加到當(dāng)前輸入文件列表的尾部。然后掃描libc.lib，這時會發(fā)現(xiàn)libc.lib里任何一個目標(biāo)模塊都沒有定義_malloc_dbg(它只在調(diào)試版的標(biāo)準(zhǔn)庫中存在)，所以不會有任何一個模塊因為_malloc_dbg而加入E，但是每個程序都要用到的初始化模塊(如crt0.obj等)及它們所引用的模塊(比如malloc.obj、free.obj等)還是會自動加入到E中，同時U和D被更新以反應(yīng)這個變化。當(dāng)鏈接器處理完libc.lib時，U只剩_malloc_dbg這一個符號。最后處理libcd.lib，發(fā)現(xiàn)dbgheap.obj定義了_malloc_dbg，于是dbgheap.obj加入到E，它里頭的未解析符號加入U，它定義的所有其它符號也加入D，這時災(zāi)難便來了。之前malloc等符號已經(jīng)在D中(隨著libc.lib里的malloc.obj加入E而加入的)，而dbgheap.obj又定義了包括malloc在內(nèi)的許多同名符號，這引發(fā)了重定義沖突，鏈接器只好中斷工作并報告錯誤。

    現(xiàn)在我們該知道，鏈接器完全沒有責(zé)任，責(zé)任在我們自己的身上。是我們粗心地把缺省標(biāo)準(zhǔn)庫版本不一致的目標(biāo)文件(main.obj)與程序庫(my.lib)鏈接起來，導(dǎo)致了大災(zāi)難。解決辦法很簡單，要么用/MLd選項來重編譯main.c；要么用/ML選項重編譯mylib.c。

    在上述例子中，我們擁有庫my.lib的源代碼(mylib.c)，所以可以用不同的選項重新編譯這些源代碼并再次打包。可如果使用的是第三方的庫，它并沒有提供源代碼，那么我們就只有改變自己程序的編譯選項來適應(yīng)這些庫了。但是如何知道庫中目標(biāo)模塊指定的默認(rèn)庫呢？其實VC提供的一個小工具便可以完成任務(wù)，這就是dumpbin.exe。運行下面這個命令

dumpbin /DIRECTIVES my.lib

然后在輸出中找那些"Linker Directives"引導(dǎo)的信息，你一定會發(fā)現(xiàn)每一處這樣的信息都會包含若干個類似"-defaultlib:XXXX"這樣的字符串，其中XXXX便代表目標(biāo)模塊指定的缺省庫名。

    知道了第三方庫指定的默認(rèn)標(biāo)準(zhǔn)庫，再用合適的選項編譯我們的應(yīng)用程序，就可以避免LNK2005和LNK1169鏈接錯誤。喜歡IDE的朋友，你一樣可以到 "Project屬性" -> "C/C++" -> "代碼生成(code generation)" -> "運行時庫(run-time library)" 項下設(shè)置應(yīng)用程序的默認(rèn)標(biāo)準(zhǔn)庫版本，這與命令行選項的效果是一樣的。