1. 為什么要在VS里引入glog日志庫選型的底層邏輯1.1 你真正需要的日志能力如果你在C項目里干過幾個月大概率會走到這一步printf打天下打到想吐調(diào)試信息散落各處線上崩潰日志全靠猜多線程環(huán)境下日志順序亂成一鍋粥。這時候就需要把日志這件事正經(jīng)地做成“基礎(chǔ)設(shè)施”而不是隨手寫幾行輸出。glog就是Google內(nèi)部那套日志系統(tǒng)開源出來的版本C項目里用得非常多尤其在Windows Visual Studio以下簡稱VS這套環(huán)境下配置得當(dāng)之后它的穩(wěn)定性和實(shí)用性非常能打。先說清楚glog到底幫你解決了什么。它不是你隨口調(diào)用的std::cout而是一套完整的日志框架核心能力包括分級日志輸出INFO / WARNING / ERROR / FATAL、按大小自動切割日志文件、每條日志自動帶時間戳和源碼位置、支持條件日志和每N條日志打一條這種細(xì)粒度控制、FATAL級別自動觸發(fā)程序終止并留下棧信息。這些能力覆蓋了絕大多數(shù)C項目對日志的真實(shí)需求從日常調(diào)試到線上問題追溯都用得上。我在真實(shí)項目里最看重的是三點(diǎn)。一是日志級別體系能讓INFO和ERROR各歸其位代碼評審時一眼就能看出哪里是正常流程、哪里是異常分支二是條件日志LOG_IF、LOG_EVERY_N這類宏能極大減少“日志刷屏”和“無效日志”的問題三是FATAL級別的崩潰鉤子配合調(diào)試器可以精確還原崩潰現(xiàn)場。所以這篇文章不打算只給一份“抄作業(yè)”式的配置步驟而是把“為什么這么配”“去哪編譯庫”“踩過哪些坑”一起講透你配置完心里有底后續(xù)擴(kuò)展也順手。1.2 主流日志庫橫評glog、spdlog、log4cplus怎么選選glog之前建議你先花兩分鐘想清楚自己的場景因?yàn)镃日志庫不止glog一個選錯方向后面會很痛苦。我日常用過的有spdlog、log4cplus、glog三套簡單對比一下對比維度glogspdloglog4cplus日志級別四級INFO/WARNING/ERROR/FATAL六級trace到critical多級可自定義性能側(cè)重中高重穩(wěn)定性極高異步模式強(qiáng)中功能全面配置方式命令行參數(shù) 環(huán)境變量代碼API配置文件上手難度低低中典型場景Google系項目、需要源碼級調(diào)試高頻日志、游戲服務(wù)器企業(yè)級老項目如果你的項目是高并發(fā)、日志量極大、對性能敏感到每秒幾萬條以上spdlog的異步模式會更強(qiáng)如果你是從Java log4j轉(zhuǎn)過來的老開發(fā)log4cplus的配置風(fēng)格你會更熟悉。但如果你是在VS里做Windows桌面程序、工具鏈軟件、客戶端組件或者團(tuán)隊本身是Google C風(fēng)格glog是最穩(wěn)的選擇。為什么這么說glog對源碼位置的記錄、對FATAL語義的處理、對崩潰信號的捕獲在Windows上配合VS的調(diào)試體驗(yàn)非常順。它不會給你整一堆用不上的配置項也沒有XML/JSON配置文件的額外學(xué)習(xí)成本編譯好之后把庫一鏈頭文件一引LOG(INFO)走天下。這篇博文全部以glog為主線展開。2. 獲取glog庫的兩種主流方式2.1 方式一vcpkg一鍵集成省心但要知道原理在VS里引入任何第三方C庫最大的痛點(diǎn)不是寫代碼而是“庫從哪來”。最省心的方案就是用vcpkg。vcpkg是微軟官方維護(hù)的C包管理器裝好之后一條命令就能把glog拉下來編譯好并且自動與VS工程集成。先看安裝vcpkg的標(biāo)準(zhǔn)流程。打開PowerShell或CMD找個干凈目錄執(zhí)行g(shù)it clone https://github.com/microsoft/vcpkg.git cd vcpkg bootstrap-vcpkg.batbootstrap-vcpkg.bat會生成vcpkg.exe然后設(shè)置環(huán)境變量或者直接調(diào)用。接著安裝glogvcpkg install glog:x64-windows這里x64-windows指定的是64位動態(tài)庫版本。如果你用的是32位工程改成x86-windows如果你想用靜態(tài)庫用x64-windows-static。這一步會拉取glog依賴的gflags等庫一起編譯耗時取決于網(wǎng)絡(luò)和機(jī)器性能。安裝完最關(guān)鍵的一步是集成到VS。繼續(xù)執(zhí)行vcpkg integrate install這個命令會在VS里注冊一個全局配置讓你新建工程后不需要手動配置頭文件路徑和庫路徑就能直接#include glog/logging.h。聽著很美好不過我建議你仍然花兩分鐘看一下它到底做了什么它本質(zhì)上是往VS的Microsoft.Cpp.x64.user屬性表里寫入了包含目錄和庫目錄。這意味著你打開任何一個VS工程的屬性頁都能在“VC目錄”里看到vcpkg的路徑。vcpkg方案適合快速搭環(huán)境、或者在多個工程之間共享同一套庫。但它有一個隱藏問題庫版本升級由vcpkg控制你沒法輕易“鎖定”某個commit如果團(tuán)隊里有人更新了vcpkg到新版本glog的行為可能發(fā)生變化導(dǎo)致你的代碼突然編譯不過或者鏈接報錯。所以如果是正式項目建議在說明文檔里固定vcpkg的git版本或者直接走源碼編譯方案。2.2 方式二源碼編譯glog可控性最強(qiáng)的路線如果你不想依賴包管理器或者需要定制glog的編譯選項或者公司內(nèi)網(wǎng)環(huán)境沒法隨意拉取vcpkg依賴那就老老實(shí)實(shí)從源碼編譯。這條路線其實(shí)不復(fù)雜我來拆解一遍。第一步獲取源碼git clone https://github.com/google/glog.git cd glog第二步用CMake生成VS工程。在glog目錄下新建一個build文件夾然后執(zhí)行cd build cmake .. -G Visual Studio 17 2022 -A x64 -DCMAKE_INSTALL_PREFIX./install這里的-G要跟你的VS版本對應(yīng)VS2019就是Visual Studio 16 2019VS2022就是Visual Studio 17 2022。-A x64指定64位架構(gòu)。CMAKE_INSTALL_PREFIX是安裝路徑我習(xí)慣放在build/install里方便后面引用。第三步編譯并安裝。直接打開生成的glog.sln用VS編譯也行我更推薦命令行方式干凈利落cmake --build . --config Release --target install注意--config ReleaseDebug版本可以單獨(dú)編一次但默認(rèn)先出Release。編譯完成后你會發(fā)現(xiàn)build/install目錄下有include和lib兩個子目錄這就是后面配置VS工程所需要的全部東西。源碼編譯方案最大的優(yōu)勢是可控。你在CMake配置階段可以加一堆開關(guān)比如-DBUILD_SHARED_LIBSOFF編靜態(tài)庫、-DWITH_GFLAGSOFF去掉gflags依賴等。對于大多數(shù)不需要gflags的工程我建議直接關(guān)掉gflags減少依賴鏈。命令如下cmake .. -G Visual Studio 17 2022 -A x64 -DCMAKE_INSTALL_PREFIX./install -DBUILD_SHARED_LIBSOFF -DWITH_GFLAGSOFF這里面BUILD_SHARED_LIBSOFF會生成靜態(tài)庫WITH_GFLAGSOFF則讓glog不依賴gflags。關(guān)掉gflags之后你在代碼里就沒法用FLAGS_v這種gflags風(fēng)格的命令行參數(shù)來控制日志了但對大部分場景沒有影響。3. VS工程配置的核心步驟3.1 工程屬性配置包含目錄、庫目錄、附加依賴項一次配齊拿到編譯好的glog無論是vcpkg還是源碼編譯下一步就是讓VS工程認(rèn)這套庫。右鍵項目 - 屬性切到“所有配置”和“所有平臺”開始配置。不要只在Debug或Release里單獨(dú)配否則換個配置就編譯不過而且很難排查。先配“VC目錄”下的“包含目錄”把include路徑填進(jìn)去。如果你用源碼編譯方案路徑就是build/install/include如果用vcpkg理論上不需要手動填但為了保險你還是可以檢查一下是否有vcpkg的路徑。然后是“庫目錄”把lib路徑填進(jìn)去比如build/install/lib。最后是“鏈接器 - 輸入 - 附加依賴項”填庫文件名。這里有一個非常關(guān)鍵的細(xì)節(jié)Release版本和Debug版本的庫文件名不一樣。通常Release版是glog.libDebug版是glogd.lib。如果你只編譯了Release庫卻用Debug配置去鏈接會直接報LNK1104 cannot open file glogd.lib。解決方案有三種一是切換到“Debug”配置再填一次Debug的庫名二是把Debug和Release都編譯出來三是用宏區(qū)分在附加依賴項里寫glog.lib然后在“鏈接器 - 輸入 - 附加依賴項”旁邊有個“繼承的值”你可以在預(yù)處理宏里加一個_DEBUG分支效果一樣。但實(shí)際項目里我強(qiáng)烈建議Debug和Release的庫都裝上因?yàn)槟憧倳贒ebug下調(diào)試。3.2 運(yùn)行庫匹配這是90%鏈接錯誤的根源配置完目錄和庫名你以為能編譯了先別急還有一個隱藏大坑運(yùn)行庫不匹配。VS的C運(yùn)行庫有兩種模式/MT靜態(tài)運(yùn)行時和/MD動態(tài)運(yùn)行時。如果你的工程用的是/MD默認(rèn)值Release最常見但編譯glog時CMake設(shè)置成了靜態(tài)運(yùn)行時鏈接時就會報一團(tuán)亂麻的錯誤最常見的是LNK2038 mismatch detected for RuntimeLibrary: value MT_StaticRelease doesnt match value MD_DynamicRelease。務(wù)必要把工程屬性和glog編譯選項對齊。檢查方式在“C/C - 代碼生成 - 運(yùn)行庫”里查看當(dāng)前值。如果你用的是/MD那么源碼編譯glog時不要額外亂改CMake的運(yùn)行庫參數(shù)直接用默認(rèn)值CMake默認(rèn)跟隨VS的設(shè)置如果你用靜態(tài)運(yùn)行時/MT則需要在CMake時指定cmake .. -DCMAKE_CXX_FLAGS_RELEASE/MT -DCMAKE_CXX_FLAGS_DEBUG/MTd其實(shí)最穩(wěn)妥的辦法是先看自己工程的運(yùn)行庫設(shè)置再據(jù)此確定glog的編譯選項兩邊一致再繼續(xù)。提示vcpkg的x64-windows默認(rèn)編的是/MD動態(tài)庫如果你的工程是/MT需要安裝x64-windows-static版。這一點(diǎn)非常容易忽略很多人配完還是報LNK2038排查半天發(fā)現(xiàn)是運(yùn)行庫不一致。4. 代碼接入與日志落地4.1 初始化glog與最常用的日志宏庫配置好之后開始寫代碼。先引入頭文件并初始化#include glog/logging.h int main(int argc, char* argv[]) { google::InitGoogleLogging(argv[0]); LOG(INFO) This is an info log; LOG(WARNING) This is a warning log; LOG(ERROR) This is an error log; google::ShutdownGoogleLogging(); return 0; }InitGoogleLogging接收程序名這個名稱會出現(xiàn)在日志文件名的前綴里。ShutdownGoogleLogging在程序退出前調(diào)用確保日志緩沖區(qū)全部落盤。寫到這里有幾個細(xì)節(jié)提醒。一是LOG(FATAL)會導(dǎo)致程序abort如果你不想讓它終止程序可以用LOG(ERROR)替代或者自定義google::InstallFailureFunction來接管FATAL行為。二是LOG_IF非常實(shí)用按條件打日志int ret DoSomething(); if (ret ! 0) { LOG(ERROR) DoSomething failed, ret ret; } // 等價寫法 LOG_IF(ERROR, ret ! 0) DoSomething failed, ret ret;三是LOG_EVERY_N控制頻次防止高頻循環(huán)里日志刷爆磁盤for (int i 0; i 100000; i) { LOG_EVERY_N(INFO, 1000) Processing i th item; }這個宏的意思是每1000次打一條日志對線上服務(wù)或者長跑分析程序來說非常有用。4.2 日志文件輸出與切割策略默認(rèn)情況下glog是輸出到stderr的在VS里跑的時候“輸出窗口”可以看到但程序關(guān)閉后日志就沒了。要落盤有兩個辦法。方法一設(shè)置標(biāo)志FLAGS_log_dir指定日志輸出目錄FLAGS_log_dir D:/logs/; google::InitGoogleLogging(argv[0]);這樣glog會自動在該目錄下生成文件命名規(guī)則是programname.hostname.user.log.severity.date.time.pid比如mytest.local.admin.log.ERROR.20241115-103025.12345。注意一旦指定了日志目錄INFO、WARNING、ERROR級別都會分別寫到對應(yīng)文件里。說到目錄這個路徑必須真實(shí)存在glog不會自動創(chuàng)建目錄路徑不存在時日志會靜默丟失。我第一次用的時候就在這里栽過因?yàn)槌绦騿訒r指定了一個不存在的目錄結(jié)果所有日志都不見了好不容易才排查出來。方法二使用glog的命令行參數(shù)機(jī)制。在InitGoogleLogging之后所有以FLAGS_開頭的變量都可以通過命令行參數(shù)覆蓋比如mytest.exe --log_dirD:/logs --minloglevel0這其實(shí)是gflags風(fēng)格的繼承如果編譯時開了gflags生效--log_dir就能直接解析。如果關(guān)掉了gflagsFLAGS_log_dir仍然存在但命令行解析功能弱化建議直接用代碼設(shè)置。日志切割由glog內(nèi)部自動處理默認(rèn)單文件超過1GB左右會觸發(fā)切割——但說實(shí)話1GB對日常開發(fā)來說太大我一般用FLAGS_max_log_size調(diào)整單位是MBFLAGS_max_log_size 100; // 單文件100MB切割然后配合FLAGS_log_level、FLAGS_stderrthreshold來精細(xì)化控制。FLAGS_stderrthreshold表示某個級別及以上的日志同時輸出到stderr比如設(shè)成google::WARNING那么WARNING和ERROR日志除了寫文件還會打到控制臺方便開發(fā)時實(shí)時看。5. 編譯鏈接常見問題排查實(shí)錄5.1 經(jīng)典LNK錯誤與運(yùn)行庫不匹配在VS里引第三方庫鏈接錯誤真是天天見我先把最常見的幾個羅列出來。LNK1104 cannot open file glog.lib庫目錄沒配對或者沒找到這個庫文件。先確認(rèn)lib目錄下確實(shí)有g(shù)log.lib如果是Debug配置下的報錯多半是你沒編譯Debug庫而附加依賴項里填了glogd.lib但文件不存在。LNK2038 RuntimeLibrary mismatch運(yùn)行庫不一致工程是/MD但glog是/MT編的或者反過來。解決辦法要么重新編glog要么改工程設(shè)置兩邊對齊。注意這個錯誤有時候不會直接報LNK2038而是變成一堆奇奇怪怪的外部符號錯誤比如__imp_??...無法解析別被表象迷惑先查運(yùn)行庫。LNK2019 unresolved external symbol class std::basic_ostream...這個也經(jīng)常是運(yùn)行庫不匹配導(dǎo)致的因?yàn)镃標(biāo)準(zhǔn)庫的實(shí)現(xiàn)方式在/MT和/MD下不同。如果錯誤堆里混合了大量STL相關(guān)符號優(yōu)先檢查運(yùn)行庫。LNK2001 unresolved external symbol void __cdecl google::InitGoogleLogging...這個更直白鏈接器找不到glog的函數(shù)實(shí)現(xiàn)。除了路徑配錯之外有一個隱蔽原因你可能沒定義GOOGLE_GLOG_DLL_DECL宏。當(dāng)glog編譯成動態(tài)庫時頭文件里的導(dǎo)出導(dǎo)入聲明依賴這個宏缺少它會導(dǎo)致找到頭文件但找不到符號。解決方案是在預(yù)處理定義里加上GOOGLE_GLOG_DLL_DECL或者在源碼編譯glog時選擇靜態(tài)庫。5.2 DLL找不到與運(yùn)行路徑問題如果你用的是動態(tài)庫版glog編譯鏈接都過了但程序一運(yùn)行就報“找不到glog.dll”。這個問題的本質(zhì)是動態(tài)庫沒有放到系統(tǒng)搜索路徑里。三個解法按優(yōu)先級排序一是把glog.dll復(fù)制到可執(zhí)行文件exe同目錄下最直接最穩(wěn)妥。二是把庫所在路徑加到系統(tǒng)環(huán)境變量PATH里但這個要重啟VS甚至重啟系統(tǒng)才生效容易造成環(huán)境污染不推薦。三是用VS的調(diào)試工作目錄設(shè)置把包含DLL的目錄設(shè)為“調(diào)試 - 工作目錄”。不過這個只在VS里調(diào)試時有效獨(dú)立運(yùn)行exe還是會報錯。我建議直接用第一種構(gòu)建后事件腳本自動拷貝copy /Y $(SolutionDir)..\lib\glog.dll $(TargetDir)如果用的是源碼編譯DLL通常都在build/install/bin下面拷到工程輸出目錄就行。注意如果同時用了多個第三方庫且它們依賴不同版本的同一個DLL那才是真正的噩夢。我遇到過glog和另一個庫都依賴不同版本的gflags導(dǎo)致運(yùn)行時崩潰。這種問題的排查思路是用dumpbin /dependents your_exe.exe查看依賴鏈把所有DLL版本對齊。5.3 多線程環(huán)境與FATAL崩潰的真實(shí)體驗(yàn)glog本身是線程安全的多線程并發(fā)打日志不會出現(xiàn)數(shù)據(jù)競爭。但有一個使用習(xí)慣要注意InitGoogleLogging和ShutdownGoogleLogging必須確保線程安全建議在main函數(shù)里單線程調(diào)用不要在全局對象構(gòu)造或析構(gòu)時觸發(fā)。FATAL日志是另一個坑。默認(rèn)情況下LOG(FATAL)會打印棧信息然后調(diào)用abort()。在Windows VS的Debug配置下你會看到一個“中斷”彈窗大部分時候這個是有用的因?yàn)樗鼛湍愣ㄎ坏搅吮罎Ⅻc(diǎn)。但在Release發(fā)布版里彈窗會影響用戶體驗(yàn)。我一般這么處理google::InstallFailureFunction([]() { // 自定義崩潰回調(diào)比如把崩潰信息發(fā)送到日志服務(wù)器 std::cerr Fatal error occurred, see log for details std::endl; });這樣FATAL時不會abort得那么粗暴但注意你替換掉默認(rèn)的abort行為后“崩潰前釋放資源、保存現(xiàn)場”這些邏輯需要你自己保證。如果你是做服務(wù)端程序建議還是保留默認(rèn)abort讓守護(hù)進(jìn)程來拉起來。還有一個問題在Windows上特別突出glog的FATAL信號捕獲對Windows的SEH結(jié)構(gòu)化異常處理支持不如Linux下的POSIX信號好。也就是說如果你的程序是因?yàn)樵L問空指針觸發(fā)的崩潰那走的是Windows異常處理機(jī)制glog默認(rèn)的InstallFailureSignalHandler不一定會捕獲到反而LOG(FATAL)這種主動觸發(fā)的FATAL能正常走鉤子。這是個很多人不知道的差異。如果你的Windows程序要捕獲完整崩潰棧建議額外用Windows自己的SetUnhandledExceptionFilter或者把glog和breakpad一起用。6. 從能用到好用glog工程的進(jìn)階配置與調(diào)試技巧6.1 多工程解決方案下如何統(tǒng)一配置glog很多人做項目不是一個工程而是有一個解決方案solution包含多個項目核心庫工程、業(yè)務(wù)庫工程、主程序工程、測試工程。如果每個工程都手動配一遍屬性維護(hù)成本很高。我的做法是用VS的屬性表Property Sheet統(tǒng)一管理。在解決方案里新建一個glog.props屬性表把這些配置寫進(jìn)去?xml version1.0 encodingutf-8? Project ToolsVersion4.0 xmlnshttp://schemas.microsoft.com/developer/msbuild/2003 PropertyGroup IncludePath$(SolutionDir)third_party\glog\include;$(IncludePath)/IncludePath LibraryPath$(SolutionDir)third_party\glog\lib\$(Configuration)\$(Platform);$(LibraryPath)/LibraryPath /PropertyGroup ItemDefinitionGroup Link AdditionalDependenciesglog.lib;%(AdditionalDependencies)/AdditionalDependencies /Link /ItemDefinitionGroup /Project然后在每個工程里右鍵“添加現(xiàn)有屬性表”這個表就會應(yīng)用到所有工程。以后升級glog版本只要替換目錄內(nèi)容或改屬性表里的路徑不需要動工程代碼。這個做法在只有兩三個工程的時候顯得多余項目一多優(yōu)勢特別明顯。還有一點(diǎn)值得做在Debug|x64和Release|x64下分別設(shè)置預(yù)處理宏。由于glog的Debug庫名是glogd.lib我通常會在屬性表里用條件表達(dá)式區(qū)分Link AdditionalDependencies Condition$(Configuration)Debugglogd.lib;%(AdditionalDependencies)/AdditionalDependencies AdditionalDependencies Condition$(Configuration)Releaseglog.lib;%(AdditionalDependencies)/AdditionalDependencies /Link這樣一勞永逸不用每個配置來回切換著填庫名。6.2 用glog進(jìn)行性能定位與線上問題排查日志除了記錄程序軌跡其實(shí)還承擔(dān)著一個重要職責(zé)性能定位。你可以在關(guān)鍵路徑前后記錄耗時用LOG(INFO)輸出時間戳配合glog自帶的時間信息就能大概判斷瓶頸。但注意日志本身也有性能開銷在for循環(huán)里每輪都打日志IO開銷會反過來拖慢程序。這時候LOG_EVERY_N和LOG_IF_EVERY_N就是救星。另外我推薦一個“統(tǒng)計型日志”的寫法在循環(huán)結(jié)束后一次性匯總打日志避免高頻日志的干擾。比如int successCount 0, failCount 0; for (...) { if (DoSomething()) successCount; else failCount; } LOG(INFO) Total: successCount failCount , success: successCount , fail: failCount;這樣在應(yīng)用日志里看到的是干凈的匯總信息排查效率遠(yuǎn)高于熬著一屏滾動的單條日志。線上排查場景里glog最有用的是ERROR和FATAL日志文件。我習(xí)慣在程序啟動時把LOG(ERROR)單獨(dú)輸出到error文件同時通過FLAGS_stderrthreshold讓控制臺只顯示W(wǎng)ARNING以上日志。這樣即使程序跑了一整天我只需要翻error日志就能定位問題不需要在幾十MB的INFO日志里大海撈針。6.3 日志序列化與自定義輸出glog的LOG(INFO) 重載支持一切可以通過ostream流輸出的類型但如果你要記錄一個自定義結(jié)構(gòu)體就得自己重載operator。我在一個通信項目里記錄數(shù)據(jù)包時這么干過struct PacketHead { uint32_t seq; uint8_t type; uint16_t len; }; std::ostream operator(std::ostream os, const PacketHead head) { os [seq head.seq , type static_castint(head.type) , len head.len ]; return os; }這樣LOG(INFO) packetHead就能直接得到可讀的輸出不需要每次打日志都寫一段代碼拼字符串。這個習(xí)慣養(yǎng)成了日志代碼的整潔度會高很多。如果你想控制日志的格式細(xì)節(jié)比如去掉文件名、行號可以用google::SetLogFilenameExtension或自定義LogMessage的回調(diào)。不過大部分場景默認(rèn)格式就夠了。7. 收尾我在實(shí)際項目中積累的幾條經(jīng)驗(yàn)最后分享幾個我踩過坑后沉淀下來的小習(xí)慣。第一glog的頭文件在Windows下偶爾會和Windows.h有符號沖突尤其是如果你還引入了windows.h建議先包含glog/logging.h再包含其他頭文件或者使用WIN32_LEAN_AND_MEAN宏避免一堆無關(guān)的Windows定義。第二如果你在同一個程序中同時用了glog和gtest一定要注意它們可能都通過gflags暴露同名變量盡量減少gflags依賴或者在編譯glog時關(guān)掉它。第三發(fā)布程序時需要把glog的DLL或靜態(tài)庫一起帶上且要同時確認(rèn)發(fā)布版本是Release編譯的否則客戶機(jī)器上會突然冒出來一堆_ITERATOR_DEBUG_LEVEL的錯誤。配置glog這件事本身不難但它涉及庫編譯、工程屬性、運(yùn)行庫匹配、頭文件引入、動態(tài)庫部署等多個環(huán)節(jié)任何一個環(huán)節(jié)出錯報錯信息都容易讓人一頭霧水。我寫這篇博文的價值就是把這些錯誤和解決方案一次性擺出來你在從零配置的時候能少走很多彎路。按上面的順序操作一遍基本十分鐘內(nèi)就能讓glog在VS的C工程里跑起來然后你就能享受一套踏實(shí)可靠的日志系統(tǒng)帶來的便利了。 VS中C++項目集成glog日志庫：從編譯到配置全解析
1. 為什么要在VS里引入glog日志庫選型的底層邏輯1.1 你真正需要的日志能力如果你在C項目里干過幾個月大概率會走到這一步printf打天下打到想吐調(diào)試信息散落各處線上崩潰日志全靠猜多線程環(huán)境下日志順序亂成一鍋粥。這時候就需要把日志這件事正經(jīng)地做成“基礎(chǔ)設(shè)施”而不是隨手寫幾行輸出。glog就是Google內(nèi)部那套日志系統(tǒng)開源出來的版本C項目里用得非常多尤其在Windows Visual Studio以下簡稱VS這套環(huán)境下配置得當(dāng)之后它的穩(wěn)定性和實(shí)用性非常能打。先說清楚glog到底幫你解決了什么。它不是你隨口調(diào)用的std::cout而是一套完整的日志框架核心能力包括分級日志輸出INFO / WARNING / ERROR / FATAL、按大小自動切割日志文件、每條日志自動帶時間戳和源碼位置、支持條件日志和每N條日志打一條這種細(xì)粒度控制、FATAL級別自動觸發(fā)程序終止并留下棧信息。這些能力覆蓋了絕大多數(shù)C項目對日志的真實(shí)需求從日常調(diào)試到線上問題追溯都用得上。我在真實(shí)項目里最看重的是三點(diǎn)。一是日志級別體系能讓INFO和ERROR各歸其位代碼評審時一眼就能看出哪里是正常流程、哪里是異常分支二是條件日志LOG_IF、LOG_EVERY_N這類宏能極大減少“日志刷屏”和“無效日志”的問題三是FATAL級別的崩潰鉤子配合調(diào)試器可以精確還原崩潰現(xiàn)場。所以這篇文章不打算只給一份“抄作業(yè)”式的配置步驟而是把“為什么這么配”“去哪編譯庫”“踩過哪些坑”一起講透你配置完心里有底后續(xù)擴(kuò)展也順手。1.2 主流日志庫橫評glog、spdlog、log4cplus怎么選選glog之前建議你先花兩分鐘想清楚自己的場景因?yàn)镃日志庫不止glog一個選錯方向后面會很痛苦。我日常用過的有spdlog、log4cplus、glog三套簡單對比一下對比維度glogspdloglog4cplus日志級別四級INFO/WARNING/ERROR/FATAL六級trace到critical多級可自定義性能側(cè)重中高重穩(wěn)定性極高異步模式強(qiáng)中功能全面配置方式命令行參數(shù) 環(huán)境變量代碼API配置文件上手難度低低中典型場景Google系項目、需要源碼級調(diào)試高頻日志、游戲服務(wù)器企業(yè)級老項目如果你的項目是高并發(fā)、日志量極大、對性能敏感到每秒幾萬條以上spdlog的異步模式會更強(qiáng)如果你是從Java log4j轉(zhuǎn)過來的老開發(fā)log4cplus的配置風(fēng)格你會更熟悉。但如果你是在VS里做Windows桌面程序、工具鏈軟件、客戶端組件或者團(tuán)隊本身是Google C風(fēng)格glog是最穩(wěn)的選擇。為什么這么說glog對源碼位置的記錄、對FATAL語義的處理、對崩潰信號的捕獲在Windows上配合VS的調(diào)試體驗(yàn)非常順。它不會給你整一堆用不上的配置項也沒有XML/JSON配置文件的額外學(xué)習(xí)成本編譯好之后把庫一鏈頭文件一引LOG(INFO)走天下。這篇博文全部以glog為主線展開。2. 獲取glog庫的兩種主流方式2.1 方式一vcpkg一鍵集成省心但要知道原理在VS里引入任何第三方C庫最大的痛點(diǎn)不是寫代碼而是“庫從哪來”。最省心的方案就是用vcpkg。vcpkg是微軟官方維護(hù)的C包管理器裝好之后一條命令就能把glog拉下來編譯好并且自動與VS工程集成。先看安裝vcpkg的標(biāo)準(zhǔn)流程。打開PowerShell或CMD找個干凈目錄執(zhí)行g(shù)it clone https://github.com/microsoft/vcpkg.git cd vcpkg bootstrap-vcpkg.batbootstrap-vcpkg.bat會生成vcpkg.exe然后設(shè)置環(huán)境變量或者直接調(diào)用。接著安裝glogvcpkg install glog:x64-windows這里x64-windows指定的是64位動態(tài)庫版本。如果你用的是32位工程改成x86-windows如果你想用靜態(tài)庫用x64-windows-static。這一步會拉取glog依賴的gflags等庫一起編譯耗時取決于網(wǎng)絡(luò)和機(jī)器性能。安裝完最關(guān)鍵的一步是集成到VS。繼續(xù)執(zhí)行vcpkg integrate install這個命令會在VS里注冊一個全局配置讓你新建工程后不需要手動配置頭文件路徑和庫路徑就能直接#include glog/logging.h。聽著很美好不過我建議你仍然花兩分鐘看一下它到底做了什么它本質(zhì)上是往VS的Microsoft.Cpp.x64.user屬性表里寫入了包含目錄和庫目錄。這意味著你打開任何一個VS工程的屬性頁都能在“VC目錄”里看到vcpkg的路徑。vcpkg方案適合快速搭環(huán)境、或者在多個工程之間共享同一套庫。但它有一個隱藏問題庫版本升級由vcpkg控制你沒法輕易“鎖定”某個commit如果團(tuán)隊里有人更新了vcpkg到新版本glog的行為可能發(fā)生變化導(dǎo)致你的代碼突然編譯不過或者鏈接報錯。所以如果是正式項目建議在說明文檔里固定vcpkg的git版本或者直接走源碼編譯方案。2.2 方式二源碼編譯glog可控性最強(qiáng)的路線如果你不想依賴包管理器或者需要定制glog的編譯選項或者公司內(nèi)網(wǎng)環(huán)境沒法隨意拉取vcpkg依賴那就老老實(shí)實(shí)從源碼編譯。這條路線其實(shí)不復(fù)雜我來拆解一遍。第一步獲取源碼git clone https://github.com/google/glog.git cd glog第二步用CMake生成VS工程。在glog目錄下新建一個build文件夾然后執(zhí)行cd build cmake .. -G Visual Studio 17 2022 -A x64 -DCMAKE_INSTALL_PREFIX./install這里的-G要跟你的VS版本對應(yīng)VS2019就是Visual Studio 16 2019VS2022就是Visual Studio 17 2022。-A x64指定64位架構(gòu)。CMAKE_INSTALL_PREFIX是安裝路徑我習(xí)慣放在build/install里方便后面引用。第三步編譯并安裝。直接打開生成的glog.sln用VS編譯也行我更推薦命令行方式干凈利落cmake --build . --config Release --target install注意--config ReleaseDebug版本可以單獨(dú)編一次但默認(rèn)先出Release。編譯完成后你會發(fā)現(xiàn)build/install目錄下有include和lib兩個子目錄這就是后面配置VS工程所需要的全部東西。源碼編譯方案最大的優(yōu)勢是可控。你在CMake配置階段可以加一堆開關(guān)比如-DBUILD_SHARED_LIBSOFF編靜態(tài)庫、-DWITH_GFLAGSOFF去掉gflags依賴等。對于大多數(shù)不需要gflags的工程我建議直接關(guān)掉gflags減少依賴鏈。命令如下cmake .. -G Visual Studio 17 2022 -A x64 -DCMAKE_INSTALL_PREFIX./install -DBUILD_SHARED_LIBSOFF -DWITH_GFLAGSOFF這里面BUILD_SHARED_LIBSOFF會生成靜態(tài)庫WITH_GFLAGSOFF則讓glog不依賴gflags。關(guān)掉gflags之后你在代碼里就沒法用FLAGS_v這種gflags風(fēng)格的命令行參數(shù)來控制日志了但對大部分場景沒有影響。3. VS工程配置的核心步驟3.1 工程屬性配置包含目錄、庫目錄、附加依賴項一次配齊拿到編譯好的glog無論是vcpkg還是源碼編譯下一步就是讓VS工程認(rèn)這套庫。右鍵項目 - 屬性切到“所有配置”和“所有平臺”開始配置。不要只在Debug或Release里單獨(dú)配否則換個配置就編譯不過而且很難排查。先配“VC目錄”下的“包含目錄”把include路徑填進(jìn)去。如果你用源碼編譯方案路徑就是build/install/include如果用vcpkg理論上不需要手動填但為了保險你還是可以檢查一下是否有vcpkg的路徑。然后是“庫目錄”把lib路徑填進(jìn)去比如build/install/lib。最后是“鏈接器 - 輸入 - 附加依賴項”填庫文件名。這里有一個非常關(guān)鍵的細(xì)節(jié)Release版本和Debug版本的庫文件名不一樣。通常Release版是glog.libDebug版是glogd.lib。如果你只編譯了Release庫卻用Debug配置去鏈接會直接報LNK1104 cannot open file glogd.lib。解決方案有三種一是切換到“Debug”配置再填一次Debug的庫名二是把Debug和Release都編譯出來三是用宏區(qū)分在附加依賴項里寫glog.lib然后在“鏈接器 - 輸入 - 附加依賴項”旁邊有個“繼承的值”你可以在預(yù)處理宏里加一個_DEBUG分支效果一樣。但實(shí)際項目里我強(qiáng)烈建議Debug和Release的庫都裝上因?yàn)槟憧倳贒ebug下調(diào)試。3.2 運(yùn)行庫匹配這是90%鏈接錯誤的根源配置完目錄和庫名你以為能編譯了先別急還有一個隱藏大坑運(yùn)行庫不匹配。VS的C運(yùn)行庫有兩種模式/MT靜態(tài)運(yùn)行時和/MD動態(tài)運(yùn)行時。如果你的工程用的是/MD默認(rèn)值Release最常見但編譯glog時CMake設(shè)置成了靜態(tài)運(yùn)行時鏈接時就會報一團(tuán)亂麻的錯誤最常見的是LNK2038 mismatch detected for RuntimeLibrary: value MT_StaticRelease doesnt match value MD_DynamicRelease。務(wù)必要把工程屬性和glog編譯選項對齊。檢查方式在“C/C - 代碼生成 - 運(yùn)行庫”里查看當(dāng)前值。如果你用的是/MD那么源碼編譯glog時不要額外亂改CMake的運(yùn)行庫參數(shù)直接用默認(rèn)值CMake默認(rèn)跟隨VS的設(shè)置如果你用靜態(tài)運(yùn)行時/MT則需要在CMake時指定cmake .. -DCMAKE_CXX_FLAGS_RELEASE/MT -DCMAKE_CXX_FLAGS_DEBUG/MTd其實(shí)最穩(wěn)妥的辦法是先看自己工程的運(yùn)行庫設(shè)置再據(jù)此確定glog的編譯選項兩邊一致再繼續(xù)。提示vcpkg的x64-windows默認(rèn)編的是/MD動態(tài)庫如果你的工程是/MT需要安裝x64-windows-static版。這一點(diǎn)非常容易忽略很多人配完還是報LNK2038排查半天發(fā)現(xiàn)是運(yùn)行庫不一致。4. 代碼接入與日志落地4.1 初始化glog與最常用的日志宏庫配置好之后開始寫代碼。先引入頭文件并初始化#include glog/logging.h int main(int argc, char* argv[]) { google::InitGoogleLogging(argv[0]); LOG(INFO) This is an info log; LOG(WARNING) This is a warning log; LOG(ERROR) This is an error log; google::ShutdownGoogleLogging(); return 0; }InitGoogleLogging接收程序名這個名稱會出現(xiàn)在日志文件名的前綴里。ShutdownGoogleLogging在程序退出前調(diào)用確保日志緩沖區(qū)全部落盤。寫到這里有幾個細(xì)節(jié)提醒。一是LOG(FATAL)會導(dǎo)致程序abort如果你不想讓它終止程序可以用LOG(ERROR)替代或者自定義google::InstallFailureFunction來接管FATAL行為。二是LOG_IF非常實(shí)用按條件打日志int ret DoSomething(); if (ret ! 0) { LOG(ERROR) DoSomething failed, ret ret; } // 等價寫法 LOG_IF(ERROR, ret ! 0) DoSomething failed, ret ret;三是LOG_EVERY_N控制頻次防止高頻循環(huán)里日志刷爆磁盤for (int i 0; i 100000; i) { LOG_EVERY_N(INFO, 1000) Processing i th item; }這個宏的意思是每1000次打一條日志對線上服務(wù)或者長跑分析程序來說非常有用。4.2 日志文件輸出與切割策略默認(rèn)情況下glog是輸出到stderr的在VS里跑的時候“輸出窗口”可以看到但程序關(guān)閉后日志就沒了。要落盤有兩個辦法。方法一設(shè)置標(biāo)志FLAGS_log_dir指定日志輸出目錄FLAGS_log_dir D:/logs/; google::InitGoogleLogging(argv[0]);這樣glog會自動在該目錄下生成文件命名規(guī)則是programname.hostname.user.log.severity.date.time.pid比如mytest.local.admin.log.ERROR.20241115-103025.12345。注意一旦指定了日志目錄INFO、WARNING、ERROR級別都會分別寫到對應(yīng)文件里。說到目錄這個路徑必須真實(shí)存在glog不會自動創(chuàng)建目錄路徑不存在時日志會靜默丟失。我第一次用的時候就在這里栽過因?yàn)槌绦騿訒r指定了一個不存在的目錄結(jié)果所有日志都不見了好不容易才排查出來。方法二使用glog的命令行參數(shù)機(jī)制。在InitGoogleLogging之后所有以FLAGS_開頭的變量都可以通過命令行參數(shù)覆蓋比如mytest.exe --log_dirD:/logs --minloglevel0這其實(shí)是gflags風(fēng)格的繼承如果編譯時開了gflags生效--log_dir就能直接解析。如果關(guān)掉了gflagsFLAGS_log_dir仍然存在但命令行解析功能弱化建議直接用代碼設(shè)置。日志切割由glog內(nèi)部自動處理默認(rèn)單文件超過1GB左右會觸發(fā)切割——但說實(shí)話1GB對日常開發(fā)來說太大我一般用FLAGS_max_log_size調(diào)整單位是MBFLAGS_max_log_size 100; // 單文件100MB切割然后配合FLAGS_log_level、FLAGS_stderrthreshold來精細(xì)化控制。FLAGS_stderrthreshold表示某個級別及以上的日志同時輸出到stderr比如設(shè)成google::WARNING那么WARNING和ERROR日志除了寫文件還會打到控制臺方便開發(fā)時實(shí)時看。5. 編譯鏈接常見問題排查實(shí)錄5.1 經(jīng)典LNK錯誤與運(yùn)行庫不匹配在VS里引第三方庫鏈接錯誤真是天天見我先把最常見的幾個羅列出來。LNK1104 cannot open file glog.lib庫目錄沒配對或者沒找到這個庫文件。先確認(rèn)lib目錄下確實(shí)有g(shù)log.lib如果是Debug配置下的報錯多半是你沒編譯Debug庫而附加依賴項里填了glogd.lib但文件不存在。LNK2038 RuntimeLibrary mismatch運(yùn)行庫不一致工程是/MD但glog是/MT編的或者反過來。解決辦法要么重新編glog要么改工程設(shè)置兩邊對齊。注意這個錯誤有時候不會直接報LNK2038而是變成一堆奇奇怪怪的外部符號錯誤比如__imp_??...無法解析別被表象迷惑先查運(yùn)行庫。LNK2019 unresolved external symbol class std::basic_ostream...這個也經(jīng)常是運(yùn)行庫不匹配導(dǎo)致的因?yàn)镃標(biāo)準(zhǔn)庫的實(shí)現(xiàn)方式在/MT和/MD下不同。如果錯誤堆里混合了大量STL相關(guān)符號優(yōu)先檢查運(yùn)行庫。LNK2001 unresolved external symbol void __cdecl google::InitGoogleLogging...這個更直白鏈接器找不到glog的函數(shù)實(shí)現(xiàn)。除了路徑配錯之外有一個隱蔽原因你可能沒定義GOOGLE_GLOG_DLL_DECL宏。當(dāng)glog編譯成動態(tài)庫時頭文件里的導(dǎo)出導(dǎo)入聲明依賴這個宏缺少它會導(dǎo)致找到頭文件但找不到符號。解決方案是在預(yù)處理定義里加上GOOGLE_GLOG_DLL_DECL或者在源碼編譯glog時選擇靜態(tài)庫。5.2 DLL找不到與運(yùn)行路徑問題如果你用的是動態(tài)庫版glog編譯鏈接都過了但程序一運(yùn)行就報“找不到glog.dll”。這個問題的本質(zhì)是動態(tài)庫沒有放到系統(tǒng)搜索路徑里。三個解法按優(yōu)先級排序一是把glog.dll復(fù)制到可執(zhí)行文件exe同目錄下最直接最穩(wěn)妥。二是把庫所在路徑加到系統(tǒng)環(huán)境變量PATH里但這個要重啟VS甚至重啟系統(tǒng)才生效容易造成環(huán)境污染不推薦。三是用VS的調(diào)試工作目錄設(shè)置把包含DLL的目錄設(shè)為“調(diào)試 - 工作目錄”。不過這個只在VS里調(diào)試時有效獨(dú)立運(yùn)行exe還是會報錯。我建議直接用第一種構(gòu)建后事件腳本自動拷貝copy /Y $(SolutionDir)..\lib\glog.dll $(TargetDir)如果用的是源碼編譯DLL通常都在build/install/bin下面拷到工程輸出目錄就行。注意如果同時用了多個第三方庫且它們依賴不同版本的同一個DLL那才是真正的噩夢。我遇到過glog和另一個庫都依賴不同版本的gflags導(dǎo)致運(yùn)行時崩潰。這種問題的排查思路是用dumpbin /dependents your_exe.exe查看依賴鏈把所有DLL版本對齊。5.3 多線程環(huán)境與FATAL崩潰的真實(shí)體驗(yàn)glog本身是線程安全的多線程并發(fā)打日志不會出現(xiàn)數(shù)據(jù)競爭。但有一個使用習(xí)慣要注意InitGoogleLogging和ShutdownGoogleLogging必須確保線程安全建議在main函數(shù)里單線程調(diào)用不要在全局對象構(gòu)造或析構(gòu)時觸發(fā)。FATAL日志是另一個坑。默認(rèn)情況下LOG(FATAL)會打印棧信息然后調(diào)用abort()。在Windows VS的Debug配置下你會看到一個“中斷”彈窗大部分時候這個是有用的因?yàn)樗鼛湍愣ㄎ坏搅吮罎Ⅻc(diǎn)。但在Release發(fā)布版里彈窗會影響用戶體驗(yàn)。我一般這么處理google::InstallFailureFunction([]() { // 自定義崩潰回調(diào)比如把崩潰信息發(fā)送到日志服務(wù)器 std::cerr Fatal error occurred, see log for details std::endl; });這樣FATAL時不會abort得那么粗暴但注意你替換掉默認(rèn)的abort行為后“崩潰前釋放資源、保存現(xiàn)場”這些邏輯需要你自己保證。如果你是做服務(wù)端程序建議還是保留默認(rèn)abort讓守護(hù)進(jìn)程來拉起來。還有一個問題在Windows上特別突出glog的FATAL信號捕獲對Windows的SEH結(jié)構(gòu)化異常處理支持不如Linux下的POSIX信號好。也就是說如果你的程序是因?yàn)樵L問空指針觸發(fā)的崩潰那走的是Windows異常處理機(jī)制glog默認(rèn)的InstallFailureSignalHandler不一定會捕獲到反而LOG(FATAL)這種主動觸發(fā)的FATAL能正常走鉤子。這是個很多人不知道的差異。如果你的Windows程序要捕獲完整崩潰棧建議額外用Windows自己的SetUnhandledExceptionFilter或者把glog和breakpad一起用。6. 從能用到好用glog工程的進(jìn)階配置與調(diào)試技巧6.1 多工程解決方案下如何統(tǒng)一配置glog很多人做項目不是一個工程而是有一個解決方案solution包含多個項目核心庫工程、業(yè)務(wù)庫工程、主程序工程、測試工程。如果每個工程都手動配一遍屬性維護(hù)成本很高。我的做法是用VS的屬性表Property Sheet統(tǒng)一管理。在解決方案里新建一個glog.props屬性表把這些配置寫進(jìn)去?xml version1.0 encodingutf-8? Project ToolsVersion4.0 xmlnshttp://schemas.microsoft.com/developer/msbuild/2003 PropertyGroup IncludePath$(SolutionDir)third_party\glog\include;$(IncludePath)/IncludePath LibraryPath$(SolutionDir)third_party\glog\lib\$(Configuration)\$(Platform);$(LibraryPath)/LibraryPath /PropertyGroup ItemDefinitionGroup Link AdditionalDependenciesglog.lib;%(AdditionalDependencies)/AdditionalDependencies /Link /ItemDefinitionGroup /Project然后在每個工程里右鍵“添加現(xiàn)有屬性表”這個表就會應(yīng)用到所有工程。以后升級glog版本只要替換目錄內(nèi)容或改屬性表里的路徑不需要動工程代碼。這個做法在只有兩三個工程的時候顯得多余項目一多優(yōu)勢特別明顯。還有一點(diǎn)值得做在Debug|x64和Release|x64下分別設(shè)置預(yù)處理宏。由于glog的Debug庫名是glogd.lib我通常會在屬性表里用條件表達(dá)式區(qū)分Link AdditionalDependencies Condition$(Configuration)Debugglogd.lib;%(AdditionalDependencies)/AdditionalDependencies AdditionalDependencies Condition$(Configuration)Releaseglog.lib;%(AdditionalDependencies)/AdditionalDependencies /Link這樣一勞永逸不用每個配置來回切換著填庫名。6.2 用glog進(jìn)行性能定位與線上問題排查日志除了記錄程序軌跡其實(shí)還承擔(dān)著一個重要職責(zé)性能定位。你可以在關(guān)鍵路徑前后記錄耗時用LOG(INFO)輸出時間戳配合glog自帶的時間信息就能大概判斷瓶頸。但注意日志本身也有性能開銷在for循環(huán)里每輪都打日志IO開銷會反過來拖慢程序。這時候LOG_EVERY_N和LOG_IF_EVERY_N就是救星。另外我推薦一個“統(tǒng)計型日志”的寫法在循環(huán)結(jié)束后一次性匯總打日志避免高頻日志的干擾。比如int successCount 0, failCount 0; for (...) { if (DoSomething()) successCount; else failCount; } LOG(INFO) Total: successCount failCount , success: successCount , fail: failCount;這樣在應(yīng)用日志里看到的是干凈的匯總信息排查效率遠(yuǎn)高于熬著一屏滾動的單條日志。線上排查場景里glog最有用的是ERROR和FATAL日志文件。我習(xí)慣在程序啟動時把LOG(ERROR)單獨(dú)輸出到error文件同時通過FLAGS_stderrthreshold讓控制臺只顯示W(wǎng)ARNING以上日志。這樣即使程序跑了一整天我只需要翻error日志就能定位問題不需要在幾十MB的INFO日志里大海撈針。6.3 日志序列化與自定義輸出glog的LOG(INFO) 重載支持一切可以通過ostream流輸出的類型但如果你要記錄一個自定義結(jié)構(gòu)體就得自己重載operator。我在一個通信項目里記錄數(shù)據(jù)包時這么干過struct PacketHead { uint32_t seq; uint8_t type; uint16_t len; }; std::ostream operator(std::ostream os, const PacketHead head) { os [seq head.seq , type static_castint(head.type) , len head.len ]; return os; }這樣LOG(INFO) packetHead就能直接得到可讀的輸出不需要每次打日志都寫一段代碼拼字符串。這個習(xí)慣養(yǎng)成了日志代碼的整潔度會高很多。如果你想控制日志的格式細(xì)節(jié)比如去掉文件名、行號可以用google::SetLogFilenameExtension或自定義LogMessage的回調(diào)。不過大部分場景默認(rèn)格式就夠了。7. 收尾我在實(shí)際項目中積累的幾條經(jīng)驗(yàn)最后分享幾個我踩過坑后沉淀下來的小習(xí)慣。第一glog的頭文件在Windows下偶爾會和Windows.h有符號沖突尤其是如果你還引入了windows.h建議先包含glog/logging.h再包含其他頭文件或者使用WIN32_LEAN_AND_MEAN宏避免一堆無關(guān)的Windows定義。第二如果你在同一個程序中同時用了glog和gtest一定要注意它們可能都通過gflags暴露同名變量盡量減少gflags依賴或者在編譯glog時關(guān)掉它。第三發(fā)布程序時需要把glog的DLL或靜態(tài)庫一起帶上且要同時確認(rèn)發(fā)布版本是Release編譯的否則客戶機(jī)器上會突然冒出來一堆_ITERATOR_DEBUG_LEVEL的錯誤。配置glog這件事本身不難但它涉及庫編譯、工程屬性、運(yùn)行庫匹配、頭文件引入、動態(tài)庫部署等多個環(huán)節(jié)任何一個環(huán)節(jié)出錯報錯信息都容易讓人一頭霧水。我寫這篇博文的價值就是把這些錯誤和解決方案一次性擺出來你在從零配置的時候能少走很多彎路。按上面的順序操作一遍基本十分鐘內(nèi)就能讓glog在VS的C工程里跑起來然后你就能享受一套踏實(shí)可靠的日志系統(tǒng)帶來的便利了。