Boost庫編譯後命名方式

boost官網的《geting started on windows》（提到了boost庫的命名，摘錄如下：

以 libboost_regex-vc71-mt-d-1_34.lib 為例：

lib

字首：除了microsoft windows之外，每乙個boost庫的名字都以此字串開始。在windows上，只有普通的靜態庫使用lib字首；導入庫和dll不使用。

boost_regex

庫名稱：所有boost庫名檔案以boost_開頭。

-vc71

toolset 標記：標識了構建該庫所用的toolset和版本。

-mt

threading 標記：標識構建該庫啟用了多執行緒支援。不支援多執行緒的庫沒有-mt。

-d abi標記：編碼了影響庫和其他編譯**互動的細節。對於每一種特性，向標記中新增乙個字母：

key use this library when:

s 靜態鏈結到c++標準庫和編譯器執行時支撐庫

g 使用標準庫和執行時支撐庫的除錯版本

y 使用python的特殊除錯構建

d 構建**的除錯版本

p 使用stlport標準庫而不是編譯器提供的預設庫

n 使用stlport已被棄用的「native iostreams」

-1_34

版本標記：完整的boost發布號，下劃線代替點。例如，1.31.1版本將被標記為「-1_31_1」。

.lib

副檔名：取決於作業系統。在大多數unix平台上，.a是靜態庫，.so是共享庫。在windows上，.dll表示共享庫，.lib是靜態或導入庫。

下表是對regex庫編譯後的檔名：

檔名含義編譯使用該庫的程式時應使用的編譯選項

libboost_regex-vc90-mt-sgd-1_38.lib 靜態庫，多執行緒，除錯版本 | 使用靜態除錯版本c執行時庫（libcmtd.lib和libcpmtd.lib） /mtd

libboost_regex-vc90-mt-s-1_38.lib 靜態庫，多執行緒

使用靜態版本c執行時庫（libcmt.lib和libcpmt.lib） /mt

libboost_regex-vc90-mt-gd-1_38.lib 靜態庫，多執行緒，除錯版本

使用動態除錯版本c執行時庫（msvcrtd.lib和msvcprtd.lib） /mdd

libboost_regex-vc90-mt-1_38.lib 靜態庫，多執行緒

使用動態版本c執行時庫（msvcrt.lib和msvcprt.lib） /md

boost_regex-vc90-mt-gd-1_38.lib 導入庫（boost_regex-vc90-mt-gd-1_38.dll），多執行緒，除錯版本

boost_regex-vc90-mt-1_38.lib 導入庫（boost_regex-vc90-mt-1_38.dll）多執行緒

[/table]

link : warning lnk4098: defaultlib '×××××' conflicts with use of other libs; use /nodefaultlib:library

原因是，當編譯時，cl.exe（也就是vc的編譯器）會根據上述編譯選項在編譯成的obj檔案中植入相應的defaultlib檔名（使用dumpbin /directive ***,lib可以檢視），如/mt對應的就是libcmt.lib（c）和libcpmt.lib（c++標準庫）。當鏈結器處理該obj檔案時，會從檔案中取出該defaultlib檔名，將其放在命令行庫列表的最後以供使用。對於靜態庫的處理也是如此，靜態庫也是由一些obj檔案組成的，每個obj檔案中也根據當時的編譯選項被植入了相應的defaultlib。當鏈結器處理靜態庫時，也會將涉及到的obj檔案中的defaultlib放在命令行庫列表的最後。假設，我們的程式使用/mt編譯，那個對應的defaultlib就是libcmt.lib（c）和libcpmt.lib（c++標準庫）。而使用的是libboost_regex-vc90-mt-sgd-1_38.lib，它對應的defaultlib就是libcmtd.lib和libcpmtd.lib。鏈結過程中，鏈結器會發現採用了不同的執行時庫，所以會出現上述錯誤。

#define boost_regex_dyn_link

#include

關於此巨集的解釋參見

**： [url]

Boost庫編譯後命名方式

Boost庫編譯後命名方式

Boost庫編譯後命名方式

Boost庫編譯後命名方式

相關推薦