簡(jiǎn)介gflags-2.1.1 是 Google 開(kāi)源命令行標(biāo)志解析庫(kù)的穩(wěn)定歷史版本面向需在 C 程序中動(dòng)態(tài)管理運(yùn)行參數(shù)的開(kāi)發(fā)者尤其是仍在維護(hù)舊版 Caffe 框架的工程人員。它將參數(shù)定義、命令行解析、配置文件讀取與 --help 幫助輸出集于一體使學(xué)習(xí)率、批處理大小等訓(xùn)練參數(shù)無(wú)需改代碼重編譯即可調(diào)整。壓縮包共 50 個(gè)文件、約 100KB以 9 個(gè) cc 源文件與 4 個(gè) h 頭文件承載核心實(shí)現(xiàn)輔以 7 個(gè) cmake 構(gòu)建腳本和 10 個(gè) in 配置模板說(shuō)明編譯安裝流程另有 txt 文檔、flagfile 示例與單元測(cè)試用例可完整走通配置到驗(yàn)證的鏈路。目前已有 222 人學(xué)習(xí)下載。讀者可獲取可直接編譯的完整源碼樹(shù)、覆蓋解析與標(biāo)志注冊(cè)的測(cè)試用例、flagfile 配置樣例及 CMake 集成參考便于在舊項(xiàng)目中復(fù)現(xiàn)穩(wěn)定行為或借此理解 gflags 的標(biāo)志注冊(cè)、參數(shù)校驗(yàn)與多語(yǔ)言接口設(shè)計(jì)。1. 版本先定死為什么 Caffe 這條鏈上偏偏要 gflags 2.1.1裝 gflags 2.1.1 這件事本身不復(fù)雜復(fù)雜的是它在 Caffe 編譯鏈里的位置。很多人第一反應(yīng)是去拉最新版結(jié)果 Caffe 一編譯就是滿(mǎn)屏的ParseCommandLineFlags is not a member of google——因?yàn)?2.2 之后默認(rèn)命名空間從google換成了gflags老代碼里寫(xiě)死的google::前綴集體失效。反過(guò)來(lái)把 2.1.1 老老實(shí)實(shí)裝進(jìn) /usr/local卻忘了執(zhí)行l(wèi)dconfig跑起來(lái)又是libgflags.so.2.1: cannot open shared object file。這套環(huán)境在復(fù)現(xiàn)老 Caffe 工程、跑只認(rèn) 2.1.x 的推理腳本、給舊版訓(xùn)練代碼補(bǔ)編譯依賴(lài)時(shí)特別常見(jiàn)裝之前把版本、prefix、命名空間三件事定死比裝完再救省事得多。2. 裝前清場(chǎng)編譯器、CMake 與系統(tǒng)里那幾份 gflags2.1 工具鏈版本下限與一條命令自檢gflags 2.1.1 的 CMakeLists.txt 里寫(xiě)的是cmake_minimum_required(VERSION 2.8.12)也就是說(shuō) CMake 已經(jīng)低到幾乎不用挑它本身還是 C98 兼容的代碼不像 2.2.2 那樣硬性要求 C11。真正卡人的是它下游的 CaffeCaffe 要 C11所以編譯器版本反而成了實(shí)際下限。我這邊常用的一套組合在下表里Ubuntu 16.04 到 20.04 都能照這個(gè)范圍配。組件最低可用我這邊實(shí)際說(shuō)明GCC / G4.87.5.0Caffe 需要 C11gflags 2.1.1 自身不需要CMake2.8.123.10.22.1.1 的構(gòu)建腳本按老版本寫(xiě)新版 CMake 也能跑make3.814.1并行編譯-j依賴(lài)它系統(tǒng)Ubuntu 16.04Ubuntu 18.04只影響包名不影響源碼編譯進(jìn)機(jī)器第一件事不是解壓源碼而是把這三條敲一遍確認(rèn)沒(méi)有多版本混裝# 確認(rèn)編譯器與構(gòu)建工具的真實(shí)指向不要只看 which gcc --version | head -1 g --version | head -1 cmake --version | head -1 make --version | head -1這里的關(guān)鍵是head -1。有些機(jī)器上/usr/bin/gcc是 7.x但 PATH 前面掛了個(gè) conda 或某個(gè)自編譯工具鏈gcc --version會(huì)打出另一套版本。Caffe 編譯時(shí)用的是 Makefile 里展開(kāi)的$(CC)和你手動(dòng)敲的未必是同一個(gè)先看清楚再往下走。提示如果你打算在同一臺(tái)機(jī)器上同時(shí)維護(hù)兩套 Caffe一套老版、一套新版建議把 gflags 裝到獨(dú)立 prefix比如/opt/gflags-2.1.1別急著塞進(jìn) /usr/local后面第 4 章會(huì)講怎么在 Makefile.config 里指過(guò)去。2.2 把系統(tǒng)自帶的 gflags 揪出來(lái)并決定怎么處理這一步是整套安裝里最容易被跳過(guò)、也最容易在鏈接期爆炸的環(huán)節(jié)。Ubuntu 的libgflags-dev裝的是 2.1.2 或 2.2.x頭文件在/usr/include/gflags/庫(kù)在/usr/lib/x86_64-linux-gnu/和你要裝的 2.1.1 完全平行。兩份頭文件、兩份 so 同時(shí)存在編譯器先看到哪一份取決于-I的順序鏈接器先找到哪一份取決于-L的順序和ld.so.cache——這就是玄學(xué)感的來(lái)源。先查清楚現(xiàn)場(chǎng)# 包管理器層面有沒(méi)有 apt 裝的 gflags dpkg -l | grep -i gflags # 文件層面三處常見(jiàn)位置分別看一眼 ls -l /usr/lib/x86_64-linux-gnu/libgflags* 2/dev/null ls -l /usr/local/lib/libgflags* 2/dev/null ls -l /usr/include/gflags/ 2/dev/null # 動(dòng)態(tài)鏈接器緩存里注冊(cè)了哪個(gè)版本 ldconfig -p | grep gflags如果dpkg -l有輸出說(shuō)明系統(tǒng)級(jí)已經(jīng)有一份。三種處理策略按你的實(shí)際情況選第一種直接卸掉sudo apt remove libgflags-dev最干凈但要注意它可能被別的包依賴(lài)apt remove會(huì)提示此時(shí)改用第二種。第二種保留但讓 /usr/local 優(yōu)先Caffe 的 Makefile.config 里INCLUDE_DIRS默認(rèn)就把/usr/local/include放在前面鏈接時(shí)-L/usr/local/lib也排在/usr/lib前面只要不動(dòng)默認(rèn)順序就不會(huì)串。第三種裝到獨(dú)立 prefix在 Caffe 里顯式指定路徑適合多人共用一臺(tái)機(jī)器、誰(shuí)也不敢動(dòng)系統(tǒng)庫(kù)的場(chǎng)景。還有一種藏得深的conda 環(huán)境。echo $CONDA_PREFIX如果有值去看$CONDA_PREFIX/lib/libgflags*和$CONDA_PREFIX/include/gflags/。conda 裝的 gflags 常常是 2.2.x而且它的include目錄會(huì)被某些構(gòu)建腳本自動(dòng)加進(jìn)搜索路徑。我一般會(huì)在編譯 Caffe 前conda deactivate把變量環(huán)境清干凈再動(dòng)手省得后面拿ldd一層層倒查。2.3 源碼包落盤(pán)與目錄約定目錄約定看著是小事實(shí)際上決定了后面出問(wèn)題時(shí)好不好回滾。我的習(xí)慣是源碼統(tǒng)一放/opt/src構(gòu)建目錄和源碼目錄分離安裝 prefix 用/usr/local——因?yàn)?Caffe 的 Makefile.config 默認(rèn)就去這兩個(gè)地方找不用改任何路徑。# 源碼統(tǒng)一存放避免散落在 home 目錄里找不回來(lái) sudo mkdir -p /opt/src cd /opt/src # 解壓后頂層目錄就是 gflags-2.1.1 sudo tar -zxvf gflags-2.1.1.tar.gz cd gflags-2.1.1 # 確認(rèn)包是完整的這幾個(gè)文件缺一個(gè)都別往下走 ls CMakeLists.txt configure.ac include/gflags/ src/解開(kāi)后應(yīng)該能看到CMakeLists.txt、configure.ac、Makefile.am、include/gflags/、src/、cmake/這幾項(xiàng)。include/gflags/下有三個(gè)頭文件gflags.h、gflags_declare.h、gflags_completions.h其中g(shù)flags_completions.h是 2.1.x 時(shí)代的東西2.2 之后被移除了后面第 5 章講升級(jí)翻車(chē)時(shí)會(huì)用到這個(gè)細(xì)節(jié)。configure.ac和Makefile.am同時(shí)存在說(shuō)明 2.1.1 還保留了 autotools 那一套這一點(diǎn)和后來(lái)的版本不一樣第 3 章末尾會(huì)單獨(dú)說(shuō)什么時(shí)候才值得走那條路。注意解壓時(shí)用tar -zxvf而不是直接雙擊解壓一是保證權(quán)限位正確二是避免某些歸檔工具把符號(hào)鏈接解成普通文件后面make會(huì)報(bào)一些莫名其妙的錯(cuò)。3. 編譯安裝gflags 2.1.1 的 CMake 參數(shù)逐個(gè)過(guò)3.1 配置階段五個(gè)開(kāi)關(guān)決定后面會(huì)不會(huì)翻車(chē)gflags 2.1.1 的 CMake 默認(rèn)值有幾個(gè)和直覺(jué)相反的地方不顯式覆蓋就會(huì)在后面某個(gè)環(huán)節(jié)找你麻煩。最典型的是BUILD_SHARED_LIBS默認(rèn) OFF——默認(rèn)只產(chǎn)出靜態(tài)庫(kù)libgflags.a而 Caffe 編出來(lái)的是libcaffe.so動(dòng)態(tài)庫(kù)鏈接沒(méi)有開(kāi) PIC 的靜態(tài)庫(kù)直接報(bào)relocation R_X86_64_32 ... can not be used when making a shared object。我用的配置命令是這樣每一條都有理由# 構(gòu)建目錄和源碼分離改參數(shù)時(shí)直接刪掉重建不留緩存 cd /opt/src/gflags-2.1.1 rm -rf build mkdir build cd build cmake .. \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIX/usr/local \ -DBUILD_SHARED_LIBSON \ -DCMAKE_POSITION_INDEPENDENT_CODEON \ -DBUILD_TESTINGOFF \ -DGFLAGS_NAMESPACEgoogleCMAKE_BUILD_TYPERelease2.1.1 不設(shè)這個(gè)變量時(shí)構(gòu)建類(lèi)型是空的編譯器不加優(yōu)化產(chǎn)出的庫(kù)性能明顯偏低。Caffe 前向推理里參數(shù)解析不是瓶頸但沒(méi)理由留個(gè) O0 的庫(kù)在系統(tǒng)里。CMAKE_INSTALL_PREFIX/usr/local這是 Caffe 默認(rèn)搜索路徑。改成別的目錄不是不行但后面 Makefile.config 的INCLUDE_DIRS和LIBRARY_DIRS都得跟著改多一處手工維護(hù)就多一處出錯(cuò)的地方。BUILD_SHARED_LIBSON產(chǎn)出libgflags.so。如果某個(gè)項(xiàng)目非要靜態(tài)鏈接2.1.1 在同一個(gè)構(gòu)建里也會(huì)生成libgflags_nothreads.a之類(lèi)夠用。反過(guò)來(lái)只編?kù)o態(tài)庫(kù)再想補(bǔ)動(dòng)態(tài)庫(kù)就得整個(gè)重編。CMAKE_POSITION_INDEPENDENT_CODEON即使這次編的是動(dòng)態(tài)庫(kù)打開(kāi)它也保險(xiǎn)。將來(lái)有人把這套 gflags 改成靜態(tài)庫(kù)鏈接進(jìn)別的 .so不會(huì)因?yàn)?PIC 再翻一次車(chē)。這一條屬于后悔藥成本幾乎為零。BUILD_TESTINGOFF不關(guān)的話(huà)2.1.1 會(huì)把gflags_unittest一起編出來(lái)多花幾十秒到幾分鐘。第一次裝建議留著跑一遍單測(cè)確認(rèn)庫(kù)本身沒(méi)問(wèn)題跑完再改 OFF 重編一次或者干脆留著反正不影響安裝產(chǎn)物。GFLAGS_NAMESPACEgoogle這條最容易被忽略。2.1.1 的默認(rèn)值本來(lái)就是google顯式寫(xiě)出來(lái)的意義在于萬(wàn)一以后有人在這份 CMakeCache 上改成gflags或者你把這套參數(shù)抄到別的版本上差異會(huì)立刻暴露而不是在 Caffe 鏈接階段才以u(píng)ndefined reference的形式出現(xiàn)。配置跑完別急著make先確認(rèn)緩存里的值真的是你寫(xiě)進(jìn)去的# 確認(rèn)關(guān)鍵變量落地防止命令行拼錯(cuò)被 CMake 靜默忽略 grep -E GFLAGS_NAMESPACE|BUILD_SHARED_LIBS|CMAKE_INSTALL_PREFIX CMakeCache.txt輸出里應(yīng)該能看到GFLAGS_NAMESPACE:STRINGgoogle、BUILD_SHARED_LIBS:BOOLON、CMAKE_INSTALL_PREFIX:PATH/usr/local。如果某個(gè)變量不見(jiàn)了多半是拼寫(xiě)問(wèn)題——CMake 對(duì)不認(rèn)識(shí)的-D變量不報(bào)錯(cuò)只在緩存里留下一個(gè) unused 警告很容易看漏。3.2 編譯安裝與 ldconfig并行度、DESTDIR 和 sudo 的邊界配置對(duì)了編譯本身沒(méi)什么懸念但有兩個(gè)細(xì)節(jié)值得說(shuō)并行度和安裝后的動(dòng)態(tài)鏈接器緩存。# 并行編譯核數(shù)用 nproc 拿別拍腦袋寫(xiě) -j8 make -j$(nproc) # 安裝到 prefix 指定的位置需要寫(xiě) /usr/local 所以要 sudo sudo make install # 刷新動(dòng)態(tài)鏈接器緩存這一步不做運(yùn)行時(shí)就找不到 so sudo ldconfigmake -j$(nproc)在小內(nèi)存機(jī)器上要小心。gflags 2.1.1 的源碼量不大一般不會(huì)因?yàn)椴⑿卸冗^(guò)高把內(nèi)存打爆但如果你的機(jī)器同時(shí)還跑著別的構(gòu)建任務(wù)-j開(kāi)到核數(shù)容易觸發(fā) OOM Killer表現(xiàn)是make突然被 kill、沒(méi)有任何報(bào)錯(cuò)。穩(wěn)妥做法是-j$(($(nproc)/2))慢一點(diǎn)但不會(huì)中斷。sudo ldconfig是必須的。/usr/local/lib在多數(shù)發(fā)行版里已經(jīng)寫(xiě)進(jìn)/etc/ld.so.conf.d/的某個(gè)配置文件中l(wèi)dconfig會(huì)把它掃進(jìn)緩存程序運(yùn)行時(shí)按 SONAME 找?guī)炀湍苊?。少了這一步make install明明成功ldd卻告訴你libgflags.so.2.1 not found很多人到這一步開(kāi)始懷疑人生。裝完立刻驗(yàn)證產(chǎn)物別等到 Caffe 編譯失敗才回頭查# 1. 庫(kù)文件應(yīng)該有實(shí)體文件和兩條符號(hào)鏈接 ls -l /usr/local/lib/libgflags* # 2. 頭文件三個(gè) .h 都在 ls -l /usr/local/include/gflags/ # 3. CMake 配置文件供 find_package 使用 ls -l /usr/local/lib/cmake/gflags/ # 4. pkg-config 文件 ls -l /usr/local/lib/pkgconfig/gflags.pc預(yù)期看到libgflags.so.2.1.1是實(shí)體libgflags.so.2.1和libgflags.so是指向它的符號(hào)鏈接。SONAME 是libgflags.so.2.1所以運(yùn)行時(shí)找的是中間那條鏈接這也是為什么后面報(bào)錯(cuò)信息里總是出現(xiàn)libgflags.so.2.1而不是2.1.1。/usr/local/lib/cmake/gflags/下的幾個(gè)文件決定了find_package(gflags)能不能走 config 模式Caffe 的 CMake 構(gòu)建會(huì)用到第 4 章展開(kāi)。gflags.pc則是 pkg-config 那條路的入口注意它裝在/usr/local/lib/pkgconfig這個(gè)路徑默認(rèn)不在pkg-config的搜索列表里需要手動(dòng)加環(huán)境變量。如果這次裝完想推倒重來(lái)2.1.1 的 Makefile 里保留了卸載規(guī)則# 卸載依賴(lài)安裝時(shí)生成的 install_manifest.txt必須在 build 目錄里執(zhí)行 cd /opt/src/gflags-2.1.1/build sudo make uninstallmake uninstall只刪它自己記錄過(guò)的文件。如果你中間手動(dòng)往/usr/local/include/gflags/里拷過(guò)東西或者裝過(guò)另一個(gè)版本覆蓋了同名文件卸載是不徹底的得手工比對(duì)install_manifest.txt清理。3.3 autotools 那條老路什么時(shí)候才值得走2.1.1 的源碼包里configure.ac和Makefile.am都還在理論上可以走./configure make make install那條經(jīng)典路徑# autotools 方式僅在 CMake 不可用時(shí)考慮 cd /opt/src/gflags-2.1.1 ./configure --prefix/usr/local --enable-shared make -j$(nproc) sudo make install命令能跑通但產(chǎn)物和 CMake 方式不一樣autotools 不會(huì)生成/usr/local/lib/cmake/gflags/那一套 config 文件。如果你的下游是 Caffe 的 CMake 構(gòu)建它走find_package(gflags)時(shí)會(huì)退回FindGFlags.cmake里的手工查找邏輯能找到庫(kù)但版本判斷和 include 路徑的推斷不如 config 模式精確。我的取舍是只要機(jī)器上有 CMake 3.x一律走 CMake。autotools 這條路留給兩種情況——一是目標(biāo)環(huán)境是某種精簡(jiǎn)系統(tǒng)CMake 裝不上二是你要做交叉編譯需要--host參數(shù)那套工具鏈傳遞機(jī)制。除此之外沒(méi)有理由繞遠(yuǎn)路。提示兩條路不要混著走。先用 autotools 裝一遍再用 CMake 裝一遍覆蓋/usr/local/lib下容易出現(xiàn)同名但來(lái)源不同的 .soldconfig之后到底加載哪個(gè)取決于文件名排序和時(shí)間戳排查起來(lái)非常費(fèi)勁。要么徹底make uninstall再換要么一開(kāi)始就選對(duì)。4. 接進(jìn) Caffe路徑怎么指、庫(kù)名怎么給4.1 Makefile.config 三個(gè)變量的填法Caffe 用 Makefile 構(gòu)建時(shí)頭文件搜索路徑和庫(kù)搜索路徑全在Makefile.config里三個(gè)變量決定 gflags 能不能被找到# Makefile.config 片段路徑類(lèi)變量的默認(rèn)值已經(jīng)包含 /usr/local INCLUDE_DIRS : $(PYTHON_INCLUDE) /usr/local/include LIBRARY_DIRS : $(PYTHON_LIB) /usr/local/lib /usr/lib # 是否用 pkg-config 找依賴(lài)默認(rèn)關(guān)閉 USE_PKG_CONFIG : 0INCLUDE_DIRS展開(kāi)后變成一堆-I參數(shù)LIBRARY_DIRS展開(kāi)成一堆-L參數(shù)。因?yàn)槟J(rèn)值里已經(jīng)有/usr/local/include和/usr/local/libgflags 裝在默認(rèn) prefix 時(shí)這三行一個(gè)字都不用改這也是第 3 章堅(jiān)持用/usr/local的原因。如果你把 gflags 裝到了別的目錄比如/opt/gflags-2.1.1就要在這兩行前面各加一項(xiàng)順序放在最前面保證優(yōu)先命中# 自定義 prefix 時(shí)放在最前面強(qiáng)制優(yōu)先 INCLUDE_DIRS : /opt/gflags-2.1.1/include $(PYTHON_INCLUDE) /usr/local/include LIBRARY_DIRS : /opt/gflags-2.1.1/lib $(PYTHON_LIB) /usr/local/lib /usr/lib順序不能反。C 編譯器的-I是按出現(xiàn)順序查找的鏈接器的-L同理誰(shuí)在前誰(shuí)生效。系統(tǒng)里同時(shí)存在/usr/include/gflags/gflags.h2.1.2 的和/usr/local/include/gflags/gflags.h2.1.1 的時(shí)順序?qū)懛淳蜁?huì)編進(jìn)另一份頭文件然后鏈接時(shí)庫(kù)又是另一份版本錯(cuò)位的經(jīng)典現(xiàn)場(chǎng)。USE_PKG_CONFIG這個(gè)開(kāi)關(guān)打開(kāi)后會(huì)走 pkg-config 找 gflags、glog、protobuf 等依賴(lài)。用它能省掉手寫(xiě)路徑但前提是gflags.pc在pkg-config的搜索路徑里。前面說(shuō)過(guò)/usr/local/lib/pkgconfig默認(rèn)不在列表內(nèi)所以要配合環(huán)境變量# 讓 pkg-config 能找到 /usr/local 下安裝的 .pc 文件 export PKG_CONFIG_PATH/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH # 驗(yàn)證版本號(hào)應(yīng)該輸出 2.1.1 pkg-config --modversion gflags pkg-config --cflags --libs gflags--modversion輸出2.1.1才算找對(duì)了。如果輸出的是2.1.2或者2.2.2說(shuō)明命中的是系統(tǒng)包的那份.pc文件檢查PKG_CONFIG_PATH有沒(méi)有生效、/usr/lib/x86_64-linux-gnu/pkgconfig/gflags.pc是不是還在。4.2 CMake 構(gòu)建 Caffe 時(shí) FindGFlags 的查找順序換到 CMake 構(gòu)建 Caffe找 gflags 的邏輯在cmake/Modules/FindGFlags.cmake里。它大致分兩步先嘗試 config 模式也就是找gflags-config.cmake找不到再退回手工find_pathfind_library在標(biāo)準(zhǔn)路徑和GFlags_ROOT之類(lèi)的提示變量里搜。判斷有沒(méi)有找對(duì)看 CMake 配置階段的這一行輸出# 在 Caffe 的 build 目錄里執(zhí)行從輸出里撈出 gflags 那一行 cmake .. 21 | grep -i gflags正確的結(jié)果長(zhǎng)這樣include 和 library 都指向/usr/localFound gflags (include: /usr/local/include, library: /usr/local/lib/libgflags.so)如果 library 指向/usr/lib/x86_64-linux-gnu/libgflags.so說(shuō)明系統(tǒng)那套搶先了如果 include 指向/usr/include而 library 指向/usr/local/lib就是典型的兩份混用必須停下來(lái)處理不能帶著這個(gè)狀態(tài)往下編譯。這種組合在鏈接期不一定報(bào)錯(cuò)但運(yùn)行時(shí)行為會(huì)非常詭異比如某些 flag 解析不出來(lái)、--help輸出缺項(xiàng)。實(shí)在要強(qiáng)制指定可以用這兩個(gè)變量覆蓋# 顯式指定繞過(guò) FindGFlags 的自動(dòng)搜索 cmake .. \ -DGFlags_INCLUDE_DIR/usr/local/include \ -DGFlags_LIBRARIES/usr/local/lib/libgflags.soCMake 的緩存機(jī)制在這里也是個(gè)坑。第一次配置時(shí)找錯(cuò)了改完環(huán)境變量重新cmake ..它可能還用緩存里的舊值。穩(wěn)妥做法是把build/CMakeCache.txt刪掉重新配置而不是反復(fù)cmake ..試運(yùn)氣。4.3 用 pkg-config 和一段 CMake 腳本先解耦驗(yàn)證在把 Caffe 牽扯進(jìn)來(lái)之前最好單獨(dú)確認(rèn) gflags 的兩種查找方式都通。pkg-config 那條剛才已經(jīng)驗(yàn)過(guò)CMake 這邊寫(xiě)個(gè)最小工程幾行就夠# /tmp/check_gflags/CMakeLists.txt cmake_minimum_required(VERSION 3.5) project(check_gflags CXX) # 走 config 模式找 /usr/local/lib/cmake/gflags/gflags-config.cmake find_package(gflags REQUIRED) message(STATUS gflags_INCLUDE_DIR ${gflags_INCLUDE_DIR}) message(STATUS gflags_LIBRARIES ${gflags_LIBRARIES})# 配置并觀察輸出不編譯任何東西 mkdir -p /tmp/check_gflags/build cd /tmp/check_gflags/build cmake .. 21 | grep gflagsfind_package(gflags REQUIRED)優(yōu)先走 config 模式2.1.1 安裝的那套gflags-config.cmake會(huì)把gflags_INCLUDE_DIR和gflags_LIBRARIES兩個(gè)變量填好。如果輸出里這兩個(gè)值都是空的但也沒(méi)報(bào)Could not find的錯(cuò)誤說(shuō)明命中了系統(tǒng)里某個(gè)不完整的 config 文件ls /usr/lib/x86_64-linux-gnu/cmake/下一層層找就能定位。這一步的價(jià)值在于把問(wèn)題隔離開(kāi)。gflags 自己的查找鏈路通了再去編 Caffe出問(wèn)題就只可能是 Caffe 的路徑配置或依賴(lài)順序不用在兩個(gè)項(xiàng)目之間來(lái)回懷疑。5. 踩坑記錄五個(gè)把編譯卡死的現(xiàn)場(chǎng)5.1 編譯鏈接階段的三次翻車(chē)坑一relocation R_X86_64_32 against symbol ... can not be used when making a shared object現(xiàn)象Caffe 的make all走到鏈接libcaffe.so那一步報(bào)錯(cuò)錯(cuò)誤信息很長(zhǎng)關(guān)鍵詞就是recompile with -fPIC。原因是 gflags 2.1.1 的 CMake 默認(rèn)BUILD_SHARED_LIBSOFF產(chǎn)出的libgflags.a沒(méi)開(kāi)位置無(wú)關(guān)代碼往動(dòng)態(tài)庫(kù)里塞就炸。解決回第 3 章的配置命令加-DBUILD_SHARED_LIBSON和-DCMAKE_POSITION_INDEPENDENT_CODEON刪掉 build 目錄重編重裝。已經(jīng)裝過(guò)靜態(tài)版的先把/usr/local/lib/libgflags.a和對(duì)應(yīng)的 cmake 配置文件清掉再裝一次別讓兩份產(chǎn)物并存?？佣ndefined reference to google::ParseCommandLineFlags(int*, char***, bool)現(xiàn)象編譯能過(guò)鏈接階段報(bào)符號(hào)找不到而且符號(hào)名里帶著google::。原因多半是頭文件和庫(kù)版本不匹配——頭文件來(lái)自 2.1.2/usr/include庫(kù)里導(dǎo)出的是別的命名空間或者鏈接順序有問(wèn)題-lgflags排在-lcaffe前面靜態(tài)庫(kù)的符號(hào)沒(méi)被拉進(jìn)來(lái)。解決先ldd .build_release/lib/libcaffe.so | grep gflags看實(shí)際鏈到了哪個(gè)路徑再nm -D /usr/local/lib/libgflags.so | grep ParseCommandLineFlags確認(rèn)符號(hào)在不在。Caffe 的 Makefile 里庫(kù)順序是寫(xiě)死的真遇到順序問(wèn)題改用 -Wl,--start-group ... -Wl,--本文還有配套的精品資源點(diǎn)擊獲取