雖然我只是一很菜很菜的菜鳥，可是卻非常迷戀gcc+gdb+vim的組合，就算現在的vc如何強大如何方便，在進行一些只使用標準庫和win sdk的程式設計時大部分時候還是在gvim裡進行的。
###/boost/tools/src> build.bat gcc即可指定使用gcc。
完成這一步後同級目錄下會生成乙個名為bin.ntx86的資料夾，裡面就有我們需要的bjam.exe。我想得到的是乙個完整編譯的版，這時將bjam.exe拷貝到###/boost/目錄下。這時就可以使用它來對整個庫進行編譯了。boost中有很多庫是直接包含標頭檔案即可使用的，而像 regex和thread等則需要編譯後才行。bjam.exe有比較多的可選執行引數，可以使用bjam –help來檢視。最常用和有用的一些解釋如下：
–toolset=
《編譯器》
//指定編譯工具
–prefix=
《庫檔案存放路徑》
//指定庫檔案存放路徑，等同stagedir
–build-type=complete //指定是否生成完全編譯版本
–with-
//只編譯指定庫
–without-
//不編譯指定庫
variant=debug|release //生成debug or release版本
link=static|shared //決定使用靜態庫還是共享庫
threading=single|multi //決定生成單執行緒還是多執行緒庫
runtime-link=static|shared //是靜態還是共享方式鏈結標準庫
我這裡想生成的是完全版本，所以啟用了–build-type=complete版本，事實證明不太有這個必要，complete版本將上述的 single|multi和static|shared及debug|release在那裡都排列組合了一番，生成的庫檔案就達1gb到2gb，而裡面有很多版本對我們平時的使用來說是不常用到的，按自己的使用需要指定版本來編譯比較好。我這裡使用的bjam命令列是：
###/boost> bjam install –toolset=gcc –prefix=」c:/boost」 –build-type=complete –without-python接下來是漫長的等待時間……按我這個命令列引數在我的機子上編譯了足足３個小時（當然，一部分是配置比較爛的後果），一部《２０１２》看完了都沒編完。
終於編譯完成之後可以看到c:/boost資料夾下有include和lib兩個資料夾，.lib和.dll檔案在lib下，而標頭檔案則放在 include資料夾下面。當我們使用的時候需要為gcc指定包含c:/boost/include/boost-1_40頭檔案目錄和c:/boost /lib庫檔案目錄。至於如何包含——到現在為止我除了知道每次在編譯時指定外還真沒找到什麼方法來為gcc指定包含路徑的方法。
就以編譯asio的chat為例，如編譯chat_server的命令行為：
g++ -d_win32_winnt -ic:/boost/include/boos-1_40chat_server.cpp -lc:/boost/lib -llibboost-thread-mingw450-mt-1_40 -llibboost-thread-mingw450-mt-1_40 -lws2_32 -o chat_server.exe
windows下使用gcc編譯boost庫
雖然我只是一很菜很菜的菜鳥，可是卻非常迷戀gcc gdb vim的組合，就算現在的vc如何強大如何方便，在進行一些只使用標準庫和win sdk的程式設計時大部分時候還是在gvim裡進行的。boost tools src build.bat gcc 即可指定使用gcc。完成這一步後同級目錄下會生成乙個...
windows下使用gcc編譯boost庫
windows下使用gcc編譯boost庫 2011年04月20日 windows下使用gcc編譯boost庫 收藏 雖然我只是一很菜很菜的菜鳥，可是卻非常迷戀gcc gdb vim的組合，就算現在的vc如何強大如何方便，在進行一些只使用標準庫和win sdk的程式設計時大部分時候還是在gvim裡進...
Windows下gcc編譯鏈結
在windows的dos下實現gcc編譯和鏈結 這裡主要看的是兩篇寫的很詳細的文章 c語言多檔案編譯初探 一 c語言多檔案編譯初探 二 3.此時就可以在dos中使用gcc了。gcc可以將c c 檔案編譯為.o檔案，然後鏈結生成可執行檔案.exe。4.接下來我們寫兩個原始檔，乙個標頭檔案，用來模擬多檔...