干了這么多年開發(fā)和運維我慢慢發(fā)現(xiàn)一個規(guī)律凡是對系統(tǒng)里某個軟件有特殊要求的人最終都會走到“源碼編譯”這條路上來。官方倉庫下載即用的二進制包確實省事可一旦你想換個編譯參數(shù)、加一個官方版本里沒帶的功能模塊或者想把軟件安裝到非標(biāo)準(zhǔn)目錄倉庫里的東西立刻就顯得束手束腳。這時候源碼編譯與定制不再是錦上添花而是唯一能讓你完整掌控軟件行為的途徑。這篇內(nèi)容本來是我整理的技術(shù)文檔里的一篇附錄按編號排到了B但實際價值一點都不“附錄”。我會從最基礎(chǔ)的動機講起到configure腳本的作用、編譯參數(shù)的取舍、常見坑的排查再到怎么把一次“編過”變成一套可持續(xù)維護的方案。適合剛接觸構(gòu)建系統(tǒng)的初學(xué)者也適合那些已經(jīng)編譯過幾次、但遇到問題總得翻文檔的人。你看完不說能成為編譯專家至少下次再拿到一份源碼包心里會清楚每一步該做什么、為什么這么做。1. 為什么選擇源碼編譯什么場景逼得你不得不走這條路1.1 官方倉庫滿足不了你的需求先說說最樸素的動機源里的版本太舊了。我見過很多項目生產(chǎn)環(huán)境跑著的軟件是兩三年前的老版本問就是“官方倉庫只有這個版本新的沒進源”。但老版本往往意味著安全漏洞沒人管、新協(xié)議不兼容、性能優(yōu)化也沒法享受。這時候拿著官方發(fā)布的新版本源碼包自己編譯就成了最直接的解法。還有一種情況更讓人頭疼官方包把功能給你閹割了。比如很多軟件為了讓安裝包體積小一點默認只編入最基礎(chǔ)的模塊一些可選功能得單獨裝擴展包或者干脆就沒提供。你恰好需要某個冷門模塊倉庫里根本沒有對應(yīng)包那就只能把源碼拉下來在configure或CMake階段把那個模塊打開重新編譯。這個過程說穿了就是“按需定制”比裝一堆你用不到的組件要干凈得多。更隱蔽的需求是編譯參數(shù)層面的定制。同一個軟件用不同的編譯優(yōu)化級別、不同的字符集、不同的第三方庫版本編出來的二進制性能表現(xiàn)和應(yīng)用場景差異很大。倉庫里的二進制包為了兼容所有機器采用的是最保守的指令集意味著它根本沒充分利用你CPU的特性。如果你跑的是計算密集型服務(wù)使用本機CPU特性重新編譯后性能提升可能非?？捎^。這種收益不是換配置能換來的只能靠源碼編譯。1.2 源碼編譯到底解決了什么問題源碼編譯解決的第一個問題是透明性。用官方預(yù)編譯包時你看到的只是黑盒里面嵌了哪些依賴、啟用了哪些功能、有沒有夾帶私貨通常要等出事了才查得清楚。自己從源碼編譯每一行代碼都擺在你面前你清楚每個功能是怎么進來的也方便在必要時做安全審計。對安全要求高的內(nèi)部系統(tǒng)來說這種透明本身就很有價值。第二個問題是可控性。你可以指定安裝前綴把軟件裝到特定目錄不污染系統(tǒng)默認路徑。多版本共存也全靠這一點同一套系統(tǒng)上可以跑兩個不同定制方案的版本只要prefix分開啟動時選不同的可執(zhí)行文件即可。這在做灰度驗證、對比測試時非常好用。第三個問題則是學(xué)習(xí)價值。我在帶團隊時特別鼓勵成員至少完整編譯一次項目源碼。當(dāng)你親眼看到configure生成Makefile、Makefile驅(qū)動編譯器鏈接器最終產(chǎn)生二進制的全過程很多“為什么這個依賴版本要固定”“為什么這個庫要靜態(tài)鏈接”的疑問一下子就有了解答。這種理解是看一百篇文檔都換不來的。1.3 什么情況不建議源碼編譯不是所有場景都適合源碼編譯我見過不少人在不需要定制的情況下強行手搓結(jié)果給運維挖了坑。比如軟件維護機制如果依賴系統(tǒng)包管理器的自動升級你一旦改成源碼安裝更新就得自己跟進相當(dāng)于把維護責(zé)任攬到自己身上。沒有人力跟進的場景寧可用舊版?zhèn)}庫包也不要編譯到一半撒手不管。另外如果系統(tǒng)自帶包完全滿足業(yè)務(wù)需求版本也不算舊那沒必要為了“顯得專業(yè)”去編譯。源碼編譯雖然不難但確實需要時間成本和環(huán)境成本。編一次還好編完之后每次上游修復(fù)漏洞你都得重新拉源碼打補丁再編譯部署這個循環(huán)如果沒人承擔(dān)就會變成技術(shù)債。還有一點容易被忽略如果你不確定自己改的編譯參數(shù)對運行時行為有什么影響就不要亂改。比如把某個安全特性disable掉能減小體積但可能直接導(dǎo)致協(xié)議握手失敗。沒有充分的測試環(huán)境貿(mào)然定制生產(chǎn)用的核心服務(wù)風(fēng)險遠大于收益。我第一次給某內(nèi)部系統(tǒng)定制編譯一個網(wǎng)絡(luò)服務(wù)時就是因為改了一個自認為無關(guān)緊要的模塊開關(guān)導(dǎo)致線上服務(wù)無法解析新版配置折騰到半夜才回滾。從那以后我給自己定了條規(guī)矩沒做過A/B驗證的編譯參數(shù)不上生產(chǎn)。2. 開始之前的準(zhǔn)備別急著敲configure2.1 構(gòu)建環(huán)境三件套很多人拿到源碼包第一件事就是解壓然后./configure然后看著滿屏報錯發(fā)愣。其實大部分失敗都源于環(huán)境缺東西。構(gòu)建環(huán)境最基礎(chǔ)的三件套是編譯器工具鏈、構(gòu)建工具和依賴庫的開發(fā)包。編譯器工具鏈包含C/C編譯器、匯編器和鏈接器等。判斷它是否可用很簡單分別在終端里執(zhí)行編譯器和構(gòu)建工具的命令看能否輸出版本信息。如果提示沒有這個命令就需要通過系統(tǒng)包管理器安裝基礎(chǔ)構(gòu)建組件。注意有些系統(tǒng)默認只裝運行時不裝開發(fā)環(huán)境這一步必須確認。依賴庫的開發(fā)包也特別關(guān)鍵。很多軟件依賴第三方函數(shù)庫比如處理加密的、處理壓縮的、處理XML的。運行一個軟件只需要庫文件但編譯這個軟件需要庫的頭文件和軟鏈接。絕大多數(shù)Linux發(fā)行版會把這兩類文件拆成“運行時”和“開發(fā)包”兩個包前者叫l(wèi)ibxxx后者叫l(wèi)ibxxx-dev或libxxx-devel。configure報錯說找不到某某頭文件時先查是不是對應(yīng)的開發(fā)包沒裝。我這里說個小建議準(zhǔn)備一臺專門用來編譯的機器或容器環(huán)境干凈且可復(fù)用不要用生產(chǎn)環(huán)境直接編譯。編譯過程中可能需要安裝一堆開發(fā)包這些包留在生產(chǎn)環(huán)境里既占空間又增加攻擊面。編譯機和運行機分離是運維上比較穩(wěn)妥的做法。2.2 源碼包來源與完整性驗證源碼包從哪來直接決定了軟件可信度。最穩(wěn)妥的做法是去軟件項目官方網(wǎng)站或官方版本庫獲取發(fā)布包不要從不知名站點隨意下載。很多項目發(fā)布時會同時提供校驗文件比如SHA256校驗和文件或者簽名文件下載后務(wù)必先驗證。校驗和驗證很簡單在命令行里計算下載文件的哈希值和官方提供的校驗值比對完全一致才繼續(xù)后續(xù)操作。簽名驗證稍微復(fù)雜一點需要導(dǎo)入發(fā)布方公鑰再做驗證但安全性更高。我遇到過下載鏈接被替換成惡意版本的情況幸好校驗時發(fā)現(xiàn)哈希不一致才避免了風(fēng)險。這個習(xí)慣后來成了我做所有源碼編譯前的默認動作屬實的“保命操作”。另外要留意源碼包的后綴名常見的有.tar.gz、.tar.xz、.zip解壓工具不同。解壓后進入目錄第一件事別看文檔先掃一眼README和INSTALL文件。里面會寫明最低依賴版本、推薦編譯參數(shù)、已知問題這些信息比網(wǎng)上零散的教程準(zhǔn)確得多。2.3 規(guī)劃安裝路徑與工作目錄源碼編譯默認安裝路徑通常是/usr/local也就是把可執(zhí)行文件扔到/usr/local/bin庫文件放到/usr/local/lib。這個前綴可以通過configure腳本或CMake的--prefix參數(shù)修改。如果你只是普通用戶沒有管理員權(quán)限完全可以把prefix設(shè)到$HOME目錄下某個子目錄實現(xiàn)用戶態(tài)安裝。我習(xí)慣把定制軟件安裝到一個獨立目錄比如/opt/apps/demoapp并把整個安裝目錄的權(quán)限單獨管理。這么做有幾個好處一是卸載時直接刪目錄就能清理干凈不影響系統(tǒng)其余部分二是可以同時裝多個版本切換時改PATH即可三是備份時只需要備份這個目錄外加配置目錄思路清晰。工作目錄則是指你解壓源碼、執(zhí)行編譯的目錄。不要把這個目錄放在/tmp下因為臨時目錄可能被系統(tǒng)清理而且不同用戶的權(quán)限也可能引發(fā)問題。建議建一個專用目錄比如~/build所有源碼包都放這里。目錄路徑最好不要帶空格否則一些老舊的構(gòu)建腳本可能處理不好。另外編譯時產(chǎn)生的對象文件特別占空間動輒幾百兆確保分區(qū)空間足夠。3. 編譯定制的核心機制configure、CMake與Makefile怎么配合3.1 configure腳本的本質(zhì)與常用參數(shù)很多人第一次見configure腳本都會覺得它很神秘一執(zhí)行就滿屏檢查。其實它的核心任務(wù)只有一件事探測當(dāng)前系統(tǒng)的環(huán)境把這些信息寫入Makefile從而保證接下來的編譯過程能適應(yīng)當(dāng)前機器。它就是一個環(huán)境適配器把源碼里“跟平臺相關(guān)”的問題提前解決掉。那構(gòu)造出Makefile之后configure還做了什么它會根據(jù)你傳入的開關(guān)參數(shù)決定哪些模塊被編譯、哪些功能被禁用。你可以把configure看成一張裝修設(shè)計圖階段的選擇器墻上開幾個插座、用不用地暖都在這個階段確定下來。裝修工人開工后就不會再問你要不要這個了因為你已經(jīng)在圖紙上表達完了。常見的參數(shù)有幾種--prefix指定安裝路徑--with-xxx啟用某個可選功能--without-xxx或--disable-xxx禁掉某個功能--enable-shared/--enable-static控制庫的鏈接方式。不同項目參數(shù)名略有差異但規(guī)律類似。在具體項目里最好的參考是執(zhí)行configure --help它會列出該軟件支持的全部開關(guān)以及含義。我拿到一個新項目源碼后第一步永遠是跑這條命令把輸出存下來然后逐個看與自己需求相關(guān)的項。還有一點要注意configure腳本并不是軟件自帶的文件而是由autoconf工具根據(jù)一份configure.ac模板生成的。有些官方發(fā)布包會直接帶生成好的configure腳本有些則要求你自己先生成后者在倉庫里通常會寫明需要autoconf和automake。遇到“沒有configure文件”的情況時先去README里查這一步。3.2 環(huán)境變量與編譯器優(yōu)化選項configure只是讀環(huán)境變量真正干活的是編譯器和鏈接器。通過環(huán)境變量你可以相當(dāng)細致地控制編譯行為最常見的是CFLAGS、CXXFLAGS和LDFLAGS。CFLAGS是給C編譯器的參數(shù)比如優(yōu)化級別、指令集架構(gòu)、警告級別CXXFLAGS對應(yīng)C項目LDFLAGS是給鏈接器的參數(shù)。優(yōu)化級別最常用的是-O2和-O3。-O2是大多數(shù)發(fā)行版默認的優(yōu)化級別兼顧性能與編譯時間-O3會做更多激進優(yōu)化可能帶來性能提升但也可能增加二進制體積甚至在極端情況下暴露出代碼里的未定義行為。我個人編譯生產(chǎn)軟件時起步用-O2只有在基準(zhǔn)測試證明-O3有收益且穩(wěn)定后才升級。本機指令集優(yōu)化可以用-marchnative讓編譯器根據(jù)當(dāng)前CPU的指令集自動生成最合適的代碼。這么做對性能有提升但產(chǎn)生的二進制只能在支持這些指令集的CPU上運行換新機器很可能會非法指令錯誤。所以它只適合確認部署環(huán)境就是當(dāng)前機器或同代CPU的情況。我在給某內(nèi)部高并發(fā)服務(wù)做定制時啟用了這個參數(shù)壓力測試下吞吐提升明顯但我也給源碼包和構(gòu)建參數(shù)單獨打了目錄標(biāo)記避免后續(xù)誤用到別的機器上。LDFLAGS則經(jīng)常用于指定額外的庫搜索路徑比如靜態(tài)鏈接到某個自定義安裝的第三方庫時需要加-L/path/to/lib和-Wl,-rpath,/path/to/lib。這里有一個容易踩的坑直接設(shè)置LD_LIBRARY_PATH可以解決運行時找不到庫的問題但它是“運行時”環(huán)境變量不是編譯期鏈接參數(shù)更穩(wěn)妥的是在編譯時通過rpath把庫路徑寫進二進制里省得到處設(shè)置環(huán)境變量。3.3 并行構(gòu)建與安裝的注意事項make命令默認是串行編譯一個文件一個文件地編對一個大型項目來說耗時很長。也可以用-j參數(shù)指定并發(fā)任務(wù)數(shù)常見的做法是-j$(nproc)其中$(nproc)是CPU核心數(shù)。并行編譯能顯著縮短時間但也別貪心內(nèi)存小的機器上開太多并行任務(wù)可能直接把內(nèi)存吃滿。并行編譯偶爾還會暴露依賴順序問題有些項目的Makefile寫得不嚴(yán)謹頭文件生成和目標(biāo)文件編譯之間沒有正確聲明依賴開高并行時會偶發(fā)編譯失敗。遇到這種情況先別急著換編譯器把并行數(shù)降下來或者干脆串行一次看是否還報錯。我遇到過某個依賴很復(fù)雜的項目-j8必現(xiàn)一個詭異的頭文件缺失錯誤-j1就一切正常后來發(fā)現(xiàn)是該項目的歷史遺留構(gòu)建腳本有問題。安裝階段通常要用管理員權(quán)限執(zhí)行make install因為默認安裝路徑往往需要寫入系統(tǒng)目錄。這里有個技巧如果prefix設(shè)置到了自己擁有寫權(quán)限的目錄那就完全不需要sudo避免權(quán)限混亂。安裝前建議執(zhí)行make -n install它會打印出安裝過程打算做哪些操作但不會真實執(zhí)行。這個“預(yù)演”功能非常實用能提前發(fā)現(xiàn)安裝過程中可能覆蓋已有文件的問題。另外一個我踩過坑的點是make install通常只拷貝文件和創(chuàng)建目錄但不會在卸載時清理它們。如果你用默認prefix裝了一套軟件后來想徹底移除會發(fā)現(xiàn)挨個找文件特別麻煩。所以從一開始就要考慮好卸載策略這直接關(guān)系到后面的維護。4. 定制實操一次典型的從源碼編譯到安裝4.1 獲取源碼與解壓為了讓流程更直觀我這里用一個虛構(gòu)的軟件包demoapp來演示它是一款帶可插拔模塊的HTTP服務(wù)程序。假設(shè)官方發(fā)布站點提供了demoapp-1.2.0.tar.gz的源碼包和一個對應(yīng)的校驗文件。第一步把它下載到~/build目錄cd ~/build wget https://example.org/dist/demoapp-1.2.0.tar.gz echo expected_sha256_value demoapp-1.2.0.tar.gz | sha256sum -c -通過校驗之后解壓tar -xzf demoapp-1.2.0.tar.gz cd demoapp-1.2.0進入目錄先別急執(zhí)行l(wèi)s看看根目錄下都有什么。通常會有configure或CMakeLists.txt、README、INSTALL、Makefile.in等。如果軟件使用CMake構(gòu)建系統(tǒng)你會看到CMakeLists.txt而不是configure。CMake的用法是單獨一個cmake命令指定源碼目錄、構(gòu)建目錄和緩存變量本質(zhì)思路和在configure階段傳參是一樣的。為了把構(gòu)建產(chǎn)物和源碼目錄分開我建議用CMake時新建一個build目錄在build目錄里執(zhí)行cmake這樣源碼目錄保持干凈。configure的項目一般可以直接在源碼目錄里編也可以支持out-of-source構(gòu)建具體看項目文檔。4.2 配置定制項假設(shè)demoapp默認會編譯大量模塊但我們只需要其中兩個核心模塊其中一個額外模塊是官方二進制包沒有的。我要做的是把它們通過configure參數(shù)開關(guān)清楚設(shè)定出來./configure --prefix/opt/apps/demoapp \ --enable-core-module \ --with-extra-feature \ --disable-unused-module \ --disable-debug這些參數(shù)的含義分別是裝到/opt/apps/demoapp啟用core模塊啟用extra特性禁用不用的模塊關(guān)閉調(diào)試輸出。configure執(zhí)行到最后如果成功通常會打印一份簡明的配置摘要列出啟用的功能、庫依賴和安裝路徑。此時回頭檢查一遍摘要確認想要的模塊都被識別到了。如果有某個模塊顯示“not found”或者“no”說明依賴不滿足或者enable參數(shù)沒被正確識別得回頭排查。我強烈建議把config.log存下來并快速瀏覽末尾幾十行。configure失敗時會在config.log里記錄具體檢測到什么問題大部分“找不到庫”“找不到頭文件”的原因都在里面寫著。光看終端輸出的錯誤信息往往不夠config.log才是全面報告。有些項目還支持通過環(huán)境變量在configure階段影響檢測結(jié)果。比如想強制鏈接某個自編譯的庫可以設(shè)置LDFLAGS和CPPFLAGS后再執(zhí)行configure。注意CPPFLAGS是給預(yù)處理器用的包含頭文件搜索路徑CFLAGS是給編譯器用的。兩者別混了否則源碼里明明有頭文件也會報找不到。4.3 編譯、安裝與驗證配置階段一切正常后開始正式編譯make -j4如果可執(zhí)行文件名帶后綴比如demoapp可執(zhí)行文件編完后直接在源碼目錄執(zhí)行./demoapp -V或類似命令看看版本號確認它能跑起來。接著安裝make install安裝完成后需要驗證幾個點可執(zhí)行文件是否在prefix目錄下動態(tài)庫是否被正確安裝并能在運行時找到配置文件樣例是否被放到了預(yù)期位置。如果prefix是/opt/apps/demoapp那一般可以這樣檢查/opt/apps/demoapp/bin/demoapp -V如果命令找不到檢查PATH里是否包含/opt/apps/demoapp/bin。lib庫則可以通過ldconfig或設(shè)置環(huán)境變量來讓系統(tǒng)找到如果只是在測試階段export LD_LIBRARY_PATH/opt/apps/demoapp/lib是快速手段但長期運行建議在系統(tǒng)配置里寫上庫路徑或者使用rpath。需要注冊成系統(tǒng)服務(wù)的場景還要額外準(zhǔn)備服務(wù)管理配置指向安裝后的可執(zhí)行文件和控制腳本。注意源碼編譯出來的軟件不會自動創(chuàng)建開機啟動項和日志輪轉(zhuǎn)配置這些都算“定制”的一部分需要自己補齊。我見過不少團隊編譯安裝一個中間件后忘記配日志切割磁盤被日志塞滿最后才急急忙忙補配置。4.4 更深層的定制操作系統(tǒng)內(nèi)核編譯流程比普通應(yīng)用軟件更進一層的源碼定制是編譯操作系統(tǒng)內(nèi)核。通常流程是下載內(nèi)核源碼、清理舊配置、用menuconfig等工具可視化調(diào)整模塊、編譯、安裝模塊、生成啟動引導(dǎo)鏡像。整個過程比編譯普通應(yīng)用復(fù)雜得多但思路相通。內(nèi)核編譯前需要額外準(zhǔn)備幾個輔助工具比如ncurses開發(fā)庫、基礎(chǔ)構(gòu)建工具、某些文件系統(tǒng)工具。配置階段推薦先基于當(dāng)前系統(tǒng)已有的配置文件生成一份默認配置然后在其上做增量調(diào)整。make menuconfig是圖形菜單界面能開啟關(guān)閉功能模塊也可以把某些模塊編譯為可動態(tài)加載模塊。不建議新手一上來就大幅裁剪功能我曾經(jīng)為了追求精簡把一個網(wǎng)卡驅(qū)動編成模塊后又忘了加入啟動鏡像結(jié)果重啟后網(wǎng)卡不工作最后只能進入單用戶模式修復(fù)。內(nèi)核編譯的耗時比普通軟件多很多參數(shù)-j的收益也更明顯。安裝模塊后要記得更新引導(dǎo)配置否則新內(nèi)核不會被啟動管理器選中。整個過程需要格外謹慎因為內(nèi)核是系統(tǒng)最底層的東西定制錯了輕則功能缺失重則無法啟動。沒有充分備份和回滾方案不要在生產(chǎn)機器上直接做內(nèi)核編譯實驗。5. 編譯過程中常見的坑與排查技巧5.1 configure階段報錯常見的configure報錯有好幾類但高頻出現(xiàn)的就幾個。第一種是“checking for xxx... not found”說明系統(tǒng)里缺少某個依賴庫的開發(fā)包。這時候去configure日志里看它具體找的是哪個函數(shù)或頭文件再用包管理器搜索對應(yīng)的dev包裝上即可。這里有一個經(jīng)驗不要盲目裝所有推薦依賴只裝缺的那個最穩(wěn)因為有些依賴版本之間有沖突。第二種是“undefined symbol”或者“cannot find -lxxx”這通常是鏈接階段找不到庫文件而不是編譯階段。原因可能是庫路徑?jīng)]被正確傳給鏈接器。面對這種情況優(yōu)先看是不是prefix配置導(dǎo)致頭文件和庫文件不在標(biāo)準(zhǔn)搜索路徑里然后通過LDFLAGS和CPPFLAGS顯式指定。第三種是版本檢測不滿足比如“requires libfoo 2.0”。系統(tǒng)里可能裝了libfoo 1.0也有l(wèi)ibfoo 2.0但位于非默認路徑。這時候要確認pkg-config能否找到這個庫。pkg-config就是個小工具它通過.pc文件提供庫的編譯參數(shù)很多configure都用它來檢測依賴?？梢杂妙愃苝kg-config --modversion foo的命令查看它識別到的版本如果識別不到設(shè)置PKG_CONFIG_PATH指到安裝前綴的lib/pkgconfig目錄即可。5.2 編譯階段的鏈接錯誤編譯階段報錯最讓人頭疼因為代碼層面的錯誤也會導(dǎo)致編譯失敗。先區(qū)分是源碼自身的問題還是環(huán)境問題。如果在干凈的官方源碼包上執(zhí)行標(biāo)準(zhǔn)configure后依然報編譯錯誤多半是工具鏈版本太新/太舊和源碼不兼容。可以搜索錯誤信息里的關(guān)鍵代碼行看看是不是某個語法在新標(biāo)準(zhǔn)里被移除了。如果確實是新舊標(biāo)準(zhǔn)問題一個繞行方案是安裝項目文檔里推薦的特定版本編譯器。鏈接錯誤中出現(xiàn)重復(fù)定義或者符號沖突時要考慮是不是混用了不同版本的庫。特別是系統(tǒng)既有老版本庫又把新版本庫裝在自定義路徑下鏈接器可能同時看到兩個版本導(dǎo)致pick了錯誤的一個。排查時通過ldd命令查看最終二進制的動態(tài)依賴再比對鏈接階段用的路徑能快速定位。另一類鏈接錯誤和靜態(tài)庫順序有關(guān)。鏈接器處理靜態(tài)庫時有順序敏感性如果庫B依賴庫A命令行里應(yīng)該寫成-lB -lA順序反了就有未定義符號。這個規(guī)則對靜態(tài)鏈接尤其明顯動態(tài)鏈接通常不這么敏感。如果遇到詭異的未定義引用問題試試調(diào)整庫選項順序或者把庫文件直接全部放進LDFLAGS里。5.3 安裝后的運行問題與卸載管理成功編譯安裝不代表萬事大吉軟件運行時可能報找不到共享庫、配置路徑不對、模塊加載失敗等問題。優(yōu)先檢查運行日志和錯誤信息里面往往給出了明確的路徑。找不到共享庫時確認庫文件確實裝到了預(yù)期路徑然后用ldconfig把路徑加入緩存或者設(shè)置LD_LIBRARY_PATH。要注意LD_LIBRARY_PATH適合臨時調(diào)試長期使用最好寫進系統(tǒng)的動態(tài)庫配置文件再執(zhí)行l(wèi)dconfig更新。卸載管理是源碼編譯里最容易欠的賬。很多項目并不提供make uninstall即使提供了也可能因為后續(xù)手動改了文件而漏刪。我現(xiàn)在做每次源碼安裝之前都會先記錄一下configure階段的完整參數(shù)并且把所有安裝產(chǎn)物集中在獨立的prefix里卸載時直接刪整個目錄。如果要更精細的管理可以借助“安裝包管理”類工具在make install時把已安裝文件列表記錄下來生成一個可以在本機卸載的軟包。這種做法雖然多一步但維護體驗好很多。還有一種常見情況你之前手動編譯安裝過一個軟件后來又想通過系統(tǒng)包管理器裝一個依賴版本結(jié)果兩者文件路徑相互覆蓋。為了避開這種混亂我堅持一個原則系統(tǒng)包管理器能解決的問題不手動編譯手動編譯的軟件一律自定義prefix不跟系統(tǒng)目錄混淆。6. 從“編過”到“會定制”可持續(xù)維護的經(jīng)驗6.1 用構(gòu)建腳本固化配置參數(shù)一次編譯成功很容易難的是三個月后上游發(fā)了一個補丁版你要升級時還能記得當(dāng)初用了什么參數(shù)。我強烈建議為每個源碼包寫一個構(gòu)建腳本把下載、校驗、解壓、configure、make、make install、驗證這個過程全部固化下來。腳本里多用變量尤其把prefix和版本號抽出來方便下次升級只改版本號。腳本還可以自動記錄configure參數(shù)的摘要到日志文件甚至把實際安裝的文件列表存下來。有了這個腳本新環(huán)境重建同樣軟件就是幾分鐘的事完全不用靠記憶重新摸一遍坑。我現(xiàn)在的習(xí)慣是每個編譯項目單獨建一個目錄里面放build.sh和READMEREADME寫明這個定制版本的目的和改了哪些參數(shù)相當(dāng)于給它建立了一個簡單檔案。6.2 在隔離環(huán)境里做完整構(gòu)建為了讓編譯過程不污染主系統(tǒng)我現(xiàn)在更傾向于在容器類隔離環(huán)境里做完整構(gòu)建。把必備依賴預(yù)先寫進構(gòu)建環(huán)境定義文件每次從干凈鏡像開始執(zhí)行構(gòu)建腳本最后把編譯產(chǎn)物拷貝到目標(biāo)機器。這樣既能復(fù)現(xiàn)構(gòu)建又不會在目標(biāo)系統(tǒng)上留下一堆開發(fā)包。對于需要固定版本依賴的場景隔離環(huán)境的價值就更明顯了。不同項目需要不同版本的第三方庫時隔離環(huán)境之間互相不干擾。我甚至?xí)涯繕?biāo)系統(tǒng)的基礎(chǔ)版本也寫進構(gòu)建環(huán)境定義確保編譯出來能直接兼容生產(chǎn)系統(tǒng)。這個做法特別適合多環(huán)境多版本維護比在一臺機器上反復(fù)切換依賴路徑舒服得多。6.3 源碼級軟件的安全跟進源碼編譯有一個繞不開的隱性成本安全更新需要自己跟進。用發(fā)行版?zhèn)}庫包時安全補丁會和系統(tǒng)更新一起推送。自編譯軟件則完全沒有這個待遇新版本發(fā)布后要自己拉取源碼對比變更重新編譯部署。這并不是“編完就結(jié)束”的說辭而是每個定制方案在決策之初就必須接受的責(zé)任。我的做法是給核心源碼軟件訂閱上游版本發(fā)布通知。一旦有重要版本或安全更新先在一個隔離環(huán)境里做升級預(yù)編譯跑完測試再規(guī)?；渴?。同時把舊版本的源碼包和構(gòu)建配置保留一段時間方便出問題時回滾。這樣雖然比自動更新多花時間但換來的是對軟件每一個變更的知情和掌控這也是當(dāng)初選擇源碼定制的核心價值所在。我個人在實際操作中體會最深的一點是源碼編譯從來不是技術(shù)難題而是習(xí)慣問題。只要每次編譯前多做一點準(zhǔn)備、把參數(shù)記錄清楚、把驗證做完整它帶來的可控性遠遠超過那點編譯時間成本。如果你也正打算對一個軟件做定制不妨從這份附錄式的流程開始一步一步來多踩幾次坑后面就順了。