鏈接器都幹了些什麼？

目前項目在不停的增長，我想還是在它規模仍舊很小的時候把它的模塊分清楚，不同模塊分到不同的 projects 裏面，這裏面出現了很多問題，也反映了我知識上的很多不足。

1 ， project 最後的輸出要設置清楚，有的是 static lib ，有的是 dll ，有的是 exe ，不一樣的輸出要設置好，它們都是 linker 的成果，但是以不同的方式應用。

2 ， project dependency 設置好， build order 什麼的，通過這些把一系列的 project 聯繫起來。

3 ， project 之間的聯繫就通過之間的 lib ， dll 來聯繫，這時候就涉及到 linker 的工作了。

許多 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

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.o

bj)

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 LIB

C.lib(sbheap.obj)

LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_region already defined i

n 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 LI

BC.lib(sbheap.obj)

LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_heapmin already defined in LIBC.li

b(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

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)" 項下設置應用程序的默認標準庫版本，這與命令行選項的效果是一樣的。

這是一片非常好的文章，如果你看到了這裏的話，那我只能恭喜你成功了！

Have fun ！

鏈接器都幹了些什麼？

《Python進階》學習筆記

Leetcode 3161. 物塊放置查詢

一個docker容器暴露多個端口

leetcode 60 排列序列

微服務實踐之使用 Visual Studio 2022 調試Dapr 應用程序

wpf附加屬性理解 WPF附加屬性

LNK2005“符號已定義”錯誤解決方法

鏈接器都幹了些什麼？

Windows中的映射模式

CListCtrl 使用心得

VC用ADO訪問數據庫全攻略

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結