C++編譯、連結過程
阿新 • • 發佈：2019-01-01
C++程式從編譯到連結然後再到呼叫的整個過程如下。 只是個人最近觀點，希望能與志同道合的同學一起討論。
注：這裡只是研究C++的主流編譯過程，與Java沒有任何關係，因為使用的技術完全不一樣（Java是編譯和解釋結合的語言）。並且由於不同的編譯器廠商對於程式的編譯過程不盡相同，但是主要流程還是一樣的。
其實長久以來我就一直很不清楚obj檔案的內容到底是什麼，有人說是彙編，有人說是機器語言。如果是機器語言的話，那編譯的過程是怎樣加入作業系統資訊的呢？因為這個問題的不斷擴充套件和困擾，便決定徹底研究一下，網上幾乎找不到相關資料，作者參照了基本系統程式設計的書籍後自行整理而來，數目見底，僅供參考，歡迎討論。
一個C++工程中會存在cpp檔案，標頭檔案，庫檔案。
1． 首先經歷的是預處理過程，將標頭檔案載入進來，並且將各種#define資訊代入。這時會見不到標頭檔案，工程經過處理後會生成以cpp檔案為基礎的編譯單元。有人可能會問那麼標頭檔案到哪裡去了。其實標頭檔案將cpp檔案中的#include替換掉了。因此在以後的程式設計中需要嚴格注意include的先後順序。因為C++語言是一種很注重申明的語言，為什麼會這樣這與程式的編譯過程和連結過程的演算法有關。貌似話題有點轉遠了，其實在這個階段是生成一個個獨力的編譯單元。
2． 在編譯單元生成之後，便是將編譯單元進行編譯，其實對於主流的編譯其實存在兩個階段，首先是生成組合語言，然後使用匯編器生成機器語言。其實這裡要講解的是組合語言怎麼變成機器語言的呢。機器語言顧名思義就是0101的二進位制程式碼。對於一個類似於MOV AX，BX（這裡寫的是Intel 80x86的彙編程式碼，其實幾乎每一種不同架構的晶片的組合語言不怎麼一樣）的程式碼而言就是將MOV和AX和BX原封不動的用0101替換掉，如MOV程式碼是35的話AX為01，BX為10的話翻譯的機器程式碼就是350110，二進位制也就是001101010000000100010000。
3． 接下來的任務是連結。連結的過程如下所示：
因為篇幅太長，請看附件。
其實連結的任務是生成可執行檔案。
其實我的一些不確認也就在這個地方。其實每一個程式都肯定有作業系統的一些資訊，比如說程式的執行環境是DOS還是Windows程式，程式的大小等。我認為編譯的整個過程中應該是在最後生成可執行檔案的時候加入的。
以上便是對於編譯，連結的整個過程。個人意見，僅作參考。
參考資料：
1. 《Thinking in C++》 Bruce Eckel 機械工業出版社
2. 《高階語言程式設計》 譚浩強 清華大學出版社
3. 《計算機組成結構化方法》 Andrew S. Tanenbaum 機械工業出版社
4. 《計算機組成與設計 硬體/軟體介面》 David A. Patterson John L. Hennessy 機械工業出版社
附件：連結器的使用
許多 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 <stdio.h>
void foo()
{
printf("%s","I am from mylib!\n");
}
用
cl /c /MLd mylib.c
（ ML 要是大寫的，否則不認。）
命令編譯，注意 /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 <crtdbg.h>
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 。連結器是不是瘋了？不，你冤枉可憐的連結器了，我拍胸脯保證它可是一直在盡心盡責地照章辦事。
輸出資訊：
C:\>link main.obj my.lib
Microsoft (R) Incremental Linker Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
LIBCD.lib(dbgheap.obj) : error LNK2005: _malloc already defined in LIBC.lib(mall oc.obj)
LIBCD.lib(dbgheap.obj) : error LNK2005: __nh_malloc already defined in LIBC.lib( malloc.obj)
LIBCD.lib(dbgheap.obj) : error LNK2005: __heap_alloc already defined in LIBC.lib (malloc.obj)
LIBCD.lib(dbgheap.obj) : error LNK2005: _free already defined in LIBC.lib(free.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: __get_sbh_threshold already defined in LI BC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: __set_sbh_threshold already defined in LI BC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_heap_init already defined in LIBC. lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_find_block already defined in LIBC .lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_free_block already defined in LIBC .lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_block already defined in LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_region already defined in LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_group already defined in LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_resize_block already defined in LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_heapmin already defined in LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_heap_check already defined in LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_threshold already defined in LIBC.lib(sbheap.obj)
LINK : warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library
main.exe : fatal error LNK1169: one or more multiply defined symbols found
一開始 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
輸出資訊：
C:\>dumpbin /DIRECTIVES my.lib
Microsoft (R) COFF Binary File Dumper Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file my.lib
File Type: LIBRARY
Linker Directives
-----------------
-defaultlib:LIBCD
-defaultlib:OLDNAMES
Summary
8 .data
27 .drectve
18 .text
然後在輸出中找那些 "Linker Directives" 引導的資訊，你一定會發現每一處這樣的資訊都會包含若干個類似 "-defaultlib:XXXX" 這樣的字串，其中 XXXX 便代表目標模組指定的預設庫名。
知道了第三方庫指定的預設標準庫，再用合適的選項編譯我們的應用程式，就可以避免 LNK2005 和 LNK1169 連結錯誤。喜歡 IDE 的朋友，你一樣可以到 "Project 屬性 " -> "C/C++" -> " 程式碼生成 (code generation)" -> " 執行時庫 (run-time library)" 項下設定應用程式的預設標準庫版本，這與命令列選項的效果是一樣的。
注：這裡只是研究C++的主流編譯過程，與Java沒有任何關係，因為使用的技術完全不一樣（Java是編譯和解釋結合的語言）。並且由於不同的編譯器廠商對於程式的編譯過程不盡相同，但是主要流程還是一樣的。
其實長久以來我就一直很不清楚obj檔案的內容到底是什麼，有人說是彙編，有人說是機器語言。如果是機器語言的話，那編譯的過程是怎樣加入作業系統資訊的呢？因為這個問題的不斷擴充套件和困擾，便決定徹底研究一下，網上幾乎找不到相關資料，作者參照了基本系統程式設計的書籍後自行整理而來，數目見底，僅供參考，歡迎討論。
一個C++工程中會存在cpp檔案，標頭檔案，庫檔案。
1． 首先經歷的是預處理過程，將標頭檔案載入進來，並且將各種#define資訊代入。這時會見不到標頭檔案，工程經過處理後會生成以cpp檔案為基礎的編譯單元。有人可能會問那麼標頭檔案到哪裡去了。其實標頭檔案將cpp檔案中的#include替換掉了。因此在以後的程式設計中需要嚴格注意include的先後順序。因為C++語言是一種很注重申明的語言，為什麼會這樣這與程式的編譯過程和連結過程的演算法有關。貌似話題有點轉遠了，其實在這個階段是生成一個個獨力的編譯單元。
2． 在編譯單元生成之後，便是將編譯單元進行編譯，其實對於主流的編譯其實存在兩個階段，首先是生成組合語言，然後使用匯編器生成機器語言。其實這裡要講解的是組合語言怎麼變成機器語言的呢。機器語言顧名思義就是0101的二進位制程式碼。對於一個類似於MOV AX，BX（這裡寫的是Intel 80x86的彙編程式碼，其實幾乎每一種不同架構的晶片的組合語言不怎麼一樣）的程式碼而言就是將MOV和AX和BX原封不動的用0101替換掉，如MOV程式碼是35的話AX為01，BX為10的話翻譯的機器程式碼就是350110，二進位制也就是001101010000000100010000。
3． 接下來的任務是連結。連結的過程如下所示：
因為篇幅太長，請看附件。
其實連結的任務是生成可執行檔案。
其實我的一些不確認也就在這個地方。其實每一個程式都肯定有作業系統的一些資訊，比如說程式的執行環境是DOS還是Windows程式，程式的大小等。我認為編譯的整個過程中應該是在最後生成可執行檔案的時候加入的。
以上便是對於編譯，連結的整個過程。個人意見，僅作參考。
參考資料：
1. 《Thinking in C++》 Bruce Eckel 機械工業出版社
2. 《高階語言程式設計》 譚浩強 清華大學出版社
3. 《計算機組成結構化方法》 Andrew S. Tanenbaum 機械工業出版社
4. 《計算機組成與設計 硬體/軟體介面》 David A. Patterson John L. Hennessy 機械工業出版社
附件：連結器的使用
許多 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 <stdio.h>
void foo()
{
printf("%s","I am from mylib!\n");
}
用
cl /c /MLd mylib.c
（ ML 要是大寫的，否則不認。）
命令編譯，注意 /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 <crtdbg.h>
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 。連結器是不是瘋了？不，你冤枉可憐的連結器了，我拍胸脯保證它可是一直在盡心盡責地照章辦事。
輸出資訊：
C:\>link main.obj my.lib
Microsoft (R) Incremental Linker Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
LIBCD.lib(dbgheap.obj) : error LNK2005: _malloc already defined in LIBC.lib(mall oc.obj)
LIBCD.lib(dbgheap.obj) : error LNK2005: __nh_malloc already defined in LIBC.lib( malloc.obj)
LIBCD.lib(dbgheap.obj) : error LNK2005: __heap_alloc already defined in LIBC.lib (malloc.obj)
LIBCD.lib(dbgheap.obj) : error LNK2005: _free already defined in LIBC.lib(free.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: __get_sbh_threshold already defined in LI BC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: __set_sbh_threshold already defined in LI BC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_heap_init already defined in LIBC. lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_find_block already defined in LIBC .lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_free_block already defined in LIBC .lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_block already defined in LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_region already defined in LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_group already defined in LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_resize_block already defined in LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_heapmin already defined in LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_heap_check already defined in LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_threshold already defined in LIBC.lib(sbheap.obj)
LINK : warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library
main.exe : fatal error LNK1169: one or more multiply defined symbols found
一開始 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
輸出資訊：
C:\>dumpbin /DIRECTIVES my.lib
Microsoft (R) COFF Binary File Dumper Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file my.lib
File Type: LIBRARY
Linker Directives
-----------------
-defaultlib:LIBCD
-defaultlib:OLDNAMES
Summary
8 .data
27 .drectve
18 .text
然後在輸出中找那些 "Linker Directives" 引導的資訊，你一定會發現每一處這樣的資訊都會包含若干個類似 "-defaultlib:XXXX" 這樣的字串，其中 XXXX 便代表目標模組指定的預設庫名。
知道了第三方庫指定的預設標準庫，再用合適的選項編譯我們的應用程式，就可以避免 LNK2005 和 LNK1169 連結錯誤。喜歡 IDE 的朋友，你一樣可以到 "Project 屬性 " -> "C/C++" -> " 程式碼生成 (code generation)" -> " 執行時庫 (run-time library)" 項下設定應用程式的預設標準庫版本，這與命令列選項的效果是一樣的。