vc link 2005錯誤

第一篇：
連接器都幹了些什麼？

（http://www.cppblog.com/jacky2019/archive/2007/03/29/20891.html）
Posted on 2007-03-29 19:10 小熊

目前項目在不停的增加，我想仍是在它規模仍舊很小的時候把它的模塊分清楚，不一樣模塊分到不一樣的 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

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

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

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

Have  fun ！



第二篇：
LNK2005 xxx already defined in libc.lib

（http://hi.baidu.com/yuanqizhu/blog/item/026f187bd7f25df10bd1879e.html）
2008-04-23 22:05  緣起助


今晚在VC6.0下編程時遇到下面這種錯誤：

源程序在沒有修改的狀況下，debug一切正常，在link release時報錯：
Linking...
LINK : warning LNK4075: ignoring /EDITANDCONTINUE due to /INCREMENTAL:NO specification
libcd.lib(dbgheap.obj) : error LNK2005: _malloc already defined in libc.lib(malloc.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: _calloc already defined in libc.lib(calloc.obj)
libcd.lib(dbgheap.obj) : error LNK2005: _realloc already defined in libc.lib(realloc.obj)
libcd.lib(dbgheap.obj) : error LNK2005: _free already defined in libc.lib(free.obj)
libcd.lib(dbgheap.obj) : error LNK2005: __msize already defined in libc.lib(msize.obj)
libcd.lib(sbheap.obj) : error LNK2005: __get_sbh_threshold already defined in libc.lib(sbheap.obj)
libcd.lib(sbheap.obj) : error LNK2005: __set_sbh_threshold already defined in libc.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)
libc.lib(crt0init.obj) : warning LNK4098: defaultlib "libcd.lib" conflicts with use of other libs; use /NODEFAULTLIB:library
Release/zfd.exe : fatal error LNK1169: one or more multiply defined symbols found
Error executing link.exe.

一看就是鏈接錯誤，libcd和libc衝突，查了下msdn，找到了辦法。
錯誤消息

默認庫「library」與其餘庫的使用衝突；請使用 /NODEFAULTLIB:library
您試圖與不兼容的庫連接。
注意
運 行時庫如今包含可防止混合不一樣類型的指令。若是試圖在同一個程序中使用不一樣類型的運行時庫或使用調試和非調試版本的運行時庫，則將收到此警告。例如，若是 編譯一個文件以使用一種運行時庫，而編譯另外一個文件以使用另外一種運行時庫（例如單線程運行時庫對多線程運行時庫），並試圖連接它們，則將獲得此警告。應將 全部源文件編譯爲使用同一個運行時庫。有關更多信息，請參見使用運行時庫（/MD、/MT 和 /LD）編譯器選項。
可使用連接器的 /VERBOSE:LIB 開關來肯定連接器搜索的庫。若是收到 LNK4098，並想建立使用如單線程、非調試運行時庫的可執行文件，請使用 /VERBOSE:LIB 選項肯定連接器搜索的庫。連接器做爲搜索的庫輸出的應是 LIBC.lib，而非 LIBCMT.lib、MSVCRT.lib、LIBCD.lib、LIBCMTD.lib 和 MSVCRTD.lib。對每一個要忽略的庫可使用 /NODEFAULTLIB，以通知連接器忽略錯誤的運行時庫。
下表顯示根據要使用的運行時庫應忽略的庫。
若要使用此運行時庫    請忽略這些庫
單線程 (libc.lib)
libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
多線程 (libcmt.lib)
libc.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
使用 DLL 的多線程 (msvcrt.lib)
libc.lib、libcmt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
調試單線程 (libcd.lib)
libc.lib、libcmt.lib、msvcrt.lib、libcmtd.lib、msvcrtd.lib
調試多線程 (libcmtd.lib)
libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、msvcrtd.lib
使用 DLL 的調試多線程 (msvcrtd.lib)
libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib

最後使用/nodefaultlib:"libcd.lib" 命令連接成功。