1. 源碼編譯與定制到底在解決什么問題很多人第一次接觸“源碼編譯與定制”這個(gè)概念是在某個(gè)開源項(xiàng)目的README里看到一行“請(qǐng)從源碼編譯安裝”的提示。那一刻的心情大概跟拿到一盒沒說明書的宜家家具差不多——零件都在但怎么拼、拼完長(zhǎng)什么樣、能不能少幾個(gè)螺絲全靠自己琢磨。我最早接觸源碼編譯是在一個(gè)嵌入式項(xiàng)目里預(yù)編譯的二進(jìn)制包跑在目標(biāo)板上總是報(bào)段錯(cuò)誤折騰了兩天最后發(fā)現(xiàn)是編譯時(shí)的浮點(diǎn)ABI選項(xiàng)跟系統(tǒng)庫對(duì)不上。從那時(shí)候起我就明白了一個(gè)道理預(yù)編譯包是別人替你做的選擇題源碼編譯是你自己出卷子。源碼編譯與定制說白了就是把別人寫好的代碼經(jīng)過配置、編譯、鏈接這一套流程變成能在你機(jī)器上跑起來的可執(zhí)行程序或庫文件并且在這個(gè)過程中按照你的需求調(diào)整功能開關(guān)、優(yōu)化參數(shù)、裁剪體積、修改行為。它解決的核心問題是“通用”與“專用”之間的矛盾。官方發(fā)布的二進(jìn)制包要照顧大多數(shù)人的使用場(chǎng)景所以默認(rèn)配置往往是大而全的帶著一堆你可能永遠(yuǎn)用不到的模塊同時(shí)又在某些細(xì)節(jié)上做了妥協(xié)。而源碼編譯讓你有機(jī)會(huì)把這些妥協(xié)一個(gè)個(gè)掰回來。適合看這部分內(nèi)容的人我大致分成三類。第一類是被預(yù)編譯包坑過的開發(fā)者比如依賴版本沖突、缺少某個(gè)編譯選項(xiàng)導(dǎo)致性能不達(dá)標(biāo)、或者目標(biāo)平臺(tái)根本沒有現(xiàn)成的二進(jìn)制包。第二類是需要深度定制的系統(tǒng)集成人員比如要把某個(gè)庫嵌到自己的產(chǎn)品里必須去掉GPL傳染性模塊、裁剪掉不需要的功能以減小體積。第三類是想搞清楚“程序是怎么來的”的學(xué)習(xí)者不滿足于apt install或者pip install想看看從一行行代碼到可執(zhí)行文件之間到底發(fā)生了什么。不管你是哪一類接下來的內(nèi)容都會(huì)從實(shí)際操作的視角把源碼編譯與定制這件事拆開揉碎講清楚。2. 編譯前的整體設(shè)計(jì)與方案選型2.1 構(gòu)建系統(tǒng)的幾種常見形態(tài)在動(dòng)手敲命令之前先得搞清楚你面對(duì)的項(xiàng)目用的是什么構(gòu)建系統(tǒng)。這就像裝修房子之前得知道是磚混結(jié)構(gòu)還是框架結(jié)構(gòu)不同結(jié)構(gòu)施工方法完全不一樣。目前主流的構(gòu)建系統(tǒng)大概有這么幾類Autotools系列configure腳本加Makefile老牌C/C項(xiàng)目的標(biāo)配。特點(diǎn)是可移植性強(qiáng)但生成的文件多、依賴鏈長(zhǎng)autoreconf有時(shí)候能跑出一堆警告。CMake跨平臺(tái)構(gòu)建工具現(xiàn)在幾乎成了C項(xiàng)目的默認(rèn)選擇。通過CMakeLists.txt描述構(gòu)建邏輯生成對(duì)應(yīng)平臺(tái)的構(gòu)建文件。靈活度高但選項(xiàng)多了之后cmake -D后面能跟一長(zhǎng)串參數(shù)。Meson Ninja新一代構(gòu)建組合速度快、語法簡(jiǎn)潔很多新項(xiàng)目開始轉(zhuǎn)向這套。依賴Python和Ninja配置階段比CMake清爽不少。語言自帶的構(gòu)建工具比如Rust的Cargo、Go的go build、Java的Maven/Gradle。這類工具通常把依賴管理和編譯打包集成在一起定制主要通過特性開關(guān)feature flag或配置文件實(shí)現(xiàn)。手寫Makefile小型項(xiàng)目或者教學(xué)示例常見直接make就完事但可定制性取決于作者寫了多少變量。選型建議很簡(jiǎn)單項(xiàng)目用什么你就用什么不要試圖換構(gòu)建系統(tǒng)。我見過有人想把Autotools項(xiàng)目硬改成CMake折騰了一周最后放棄了純屬給自己找不痛快。你要做的是理解當(dāng)前構(gòu)建系統(tǒng)的配置入口在哪里而不是重新發(fā)明輪子。2.2 編譯定制的主要維度源碼編譯的“定制”不是瞎改而是有明確的維度可以操作。根據(jù)我這些年的經(jīng)驗(yàn)定制需求基本落在下面幾個(gè)方向上定制維度典型需求常用手段功能裁剪去掉不需要的模塊減小體積配置選項(xiàng)開關(guān)、條件編譯宏性能優(yōu)化針對(duì)特定CPU指令集優(yōu)化編譯選項(xiàng)如-O3、-marchnative依賴調(diào)整使用系統(tǒng)庫還是自帶庫--with-xxx、-DUSE_SYSTEM_XXX安裝路徑裝到自定義目錄而非系統(tǒng)目錄--prefix、CMAKE_INSTALL_PREFIX調(diào)試支持保留符號(hào)信息、開啟日志-g、--enable-debug靜態(tài)/動(dòng)態(tài)鏈接生成靜態(tài)庫便于分發(fā)--enable-static、BUILD_SHARED_LIBS交叉編譯為目標(biāo)平臺(tái)而非本機(jī)編譯--host、工具鏈文件這些維度不是孤立的很多時(shí)候需要組合使用。比如你要給一個(gè)嵌入式設(shè)備編譯一個(gè)精簡(jiǎn)版庫可能同時(shí)需要裁剪功能、指定交叉編譯工具鏈、設(shè)置安裝路徑到臨時(shí)目錄、并且生成靜態(tài)庫。提前把需求列清楚比邊編譯邊改要高效得多。2.3 環(huán)境準(zhǔn)備的核心檢查項(xiàng)環(huán)境準(zhǔn)備這一步很多人覺得裝個(gè)編譯器就完事了實(shí)際上坑最多。我總結(jié)了一個(gè)檢查清單每次在新機(jī)器上編譯之前都會(huì)過一遍編譯器版本項(xiàng)目要求的GCC/Clang最低版本是多少gcc --version看一眼。C項(xiàng)目尤其要注意C11、C14、C17的編譯器支持差異很大。構(gòu)建工具鏈make、cmake、ninja、pkg-config、autoconf、automake、libtool這些是否齊全版本是否滿足要求開發(fā)庫和頭文件很多編譯失敗是因?yàn)槿鄙?dev或-devel包。比如編譯一個(gè)依賴zlib的項(xiàng)目光有zlib1g不夠還得有zlib1g-dev。Python環(huán)境現(xiàn)在很多構(gòu)建系統(tǒng)用Python腳本做配置或代碼生成Python版本和必要的模塊如setuptools要確認(rèn)。磁盤空間源碼編譯過程中產(chǎn)生的中間文件可能比源碼大好幾倍尤其是C項(xiàng)目。df -h看一眼留出至少幾個(gè)GB的余量。網(wǎng)絡(luò)與鏡像如果構(gòu)建過程需要下載依賴提前配置好可用的軟件源避免編譯到一半卡在下載上。注意不要用root用戶直接編譯。很多項(xiàng)目的構(gòu)建腳本會(huì)往當(dāng)前目錄寫文件root權(quán)限下可能覆蓋系統(tǒng)文件或者產(chǎn)生權(quán)限混亂。用普通用戶編譯最后安裝階段再提權(quán)。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 配置階段的參數(shù)拆解配置階段是源碼編譯的靈魂。以最常見的./configure為例它做的事情其實(shí)是探測(cè)你的系統(tǒng)環(huán)境然后生成適配的Makefile。這個(gè)過程中你傳給它的參數(shù)決定了最終產(chǎn)物長(zhǎng)什么樣。先看幾個(gè)最基礎(chǔ)也最關(guān)鍵的參數(shù)--prefix/your/path指定安裝路徑。默認(rèn)是/usr/local但很多時(shí)候我們希望裝到獨(dú)立目錄便于管理比如/opt/myapp或者用戶家目錄下的~/local。這個(gè)參數(shù)影響后續(xù)make install把文件復(fù)制到哪里。--enable-xxx/--disable-xxx功能開關(guān)。--disable-xxx通常用來關(guān)掉不需要的模塊減少編譯時(shí)間和最終體積。比如編譯一個(gè)圖像庫時(shí)如果你只需要PNG支持就可以--disable-jpeg --disable-tiff。--with-xxx/path/--without-xxx依賴庫路徑指定。當(dāng)某個(gè)依賴裝在非標(biāo)準(zhǔn)路徑時(shí)用這個(gè)告訴配置腳本去哪里找。--without-xxx則是明確不使用某個(gè)可選依賴。--host/--build/--target交叉編譯三件套。--build是你當(dāng)前編譯用的機(jī)器--host是編譯出來的程序要運(yùn)行的機(jī)器--target只在編譯編譯器本身時(shí)才用得到。交叉編譯時(shí)通常只需要指定--host。CMake項(xiàng)目的參數(shù)形式不同但邏輯類似。-DCMAKE_INSTALL_PREFIX/your/path對(duì)應(yīng)--prefix-DBUILD_SHARED_LIBSOFF對(duì)應(yīng)生成靜態(tài)庫-DCMAKE_BUILD_TYPERelease控制優(yōu)化級(jí)別。CMake的選項(xiàng)通常以-D開頭后面跟變量名值。我個(gè)人的習(xí)慣是在配置之前先跑一次./configure --help或者cmake -L把項(xiàng)目支持的所有選項(xiàng)列出來看一遍。這一步花不了幾分鐘但能避免“編譯完了才發(fā)現(xiàn)有個(gè)選項(xiàng)沒開”的尷尬。3.2 編譯階段的并行與優(yōu)化配置完成之后就是make或者cmake --build。這里最值得說的兩個(gè)點(diǎn)并行編譯和優(yōu)化選項(xiàng)。并行編譯用-j參數(shù)指定并行任務(wù)數(shù)。經(jīng)驗(yàn)公式是CPU核心數(shù) 1比如4核機(jī)器用make -j5。但這不是絕對(duì)的如果項(xiàng)目依賴關(guān)系復(fù)雜并行數(shù)太高反而會(huì)因?yàn)榈却蕾嚩档托?。我一般先用nproc看一下核心數(shù)然后從-j$(nproc)開始試如果出現(xiàn)奇怪的編譯錯(cuò)誤就降到-j4甚至-j1排查。優(yōu)化選項(xiàng)方面-O2是大多數(shù)項(xiàng)目的默認(rèn)值平衡了性能和編譯時(shí)間。-O3會(huì)開啟更激進(jìn)的優(yōu)化可能提升性能但也可能增大體積某些情況下甚至因?yàn)檫^度優(yōu)化引入bug。-Os專門優(yōu)化體積適合嵌入式場(chǎng)景。-marchnative讓編譯器針對(duì)當(dāng)前CPU生成指令能榨出一些性能但編譯出來的程序換一臺(tái)機(jī)器可能就跑不了。實(shí)操心得如果編譯過程中出現(xiàn)“internal compiler error”或者段錯(cuò)誤第一反應(yīng)應(yīng)該是降低優(yōu)化級(jí)別或者減少并行數(shù)。編譯器本身也是程序也會(huì)因?yàn)橘Y源競(jìng)爭(zhēng)或者優(yōu)化bug崩潰。我遇到過好幾次-j16編譯大型C項(xiàng)目時(shí)gcc內(nèi)部錯(cuò)誤降到-j4就順利通過了。3.3 安裝與打包的路徑管理make install這一步看似簡(jiǎn)單但路徑管理不當(dāng)會(huì)帶來很多后續(xù)麻煩。核心原則是不要污染系統(tǒng)目錄除非你明確知道自己在做什么。推薦的做法是安裝到獨(dú)立前綴比如/opt/softwarename/version/。這樣不同版本可以共存卸載的時(shí)候直接刪目錄就行不會(huì)留下散落在/usr/lib、/usr/include里的文件。如果只是自己用裝到~/.local或者~/opt也完全可以。對(duì)于需要分發(fā)的場(chǎng)景可以用DESTDIR機(jī)制做暫存安裝。make install DESTDIR/tmp/staging會(huì)把文件安裝到/tmp/staging/your/prefix/下面然后你可以用打包工具把這個(gè)目錄打成deb、rpm或者tar包。這樣做的好處是構(gòu)建和打包分離不會(huì)因?yàn)榇虬《廴鞠到y(tǒng)。CMake項(xiàng)目對(duì)應(yīng)的是cmake --install . --prefix /your/path或者設(shè)置DESTDIR環(huán)境變量。邏輯是一樣的。3.4 源碼級(jí)定制的幾種手法有時(shí)候配置選項(xiàng)滿足不了需求就得動(dòng)源碼。源碼級(jí)定制聽起來嚇人但實(shí)際上大部分場(chǎng)景下只是改幾個(gè)宏定義或者條件編譯分支。最常見的是修改config.h或者類似的配置頭文件。很多項(xiàng)目在配置階段會(huì)生成一個(gè)包含各種#define的頭文件你可以直接編輯它來開啟或關(guān)閉某些特性然后重新編譯。這種方式的優(yōu)點(diǎn)是改動(dòng)集中、容易回滾。其次是修改構(gòu)建腳本中的編譯選項(xiàng)。比如在Makefile或者CMakeLists.txt里找到CFLAGS或CXXFLAGS追加你需要的選項(xiàng)。這種方式適合臨時(shí)調(diào)整但不適合長(zhǎng)期維護(hù)因?yàn)橄麓沃匦屡渲脮r(shí)改動(dòng)就丟了。更深層的定制是修改功能代碼本身。比如某個(gè)函數(shù)的行為不符合你的需求你可以直接改源碼然后重新編譯。但這種方式要謹(jǐn)慎因?yàn)楦耐曛竽憔透嫌未a分叉了后續(xù)升級(jí)合并會(huì)很痛苦。我的建議是能用配置選項(xiàng)解決的絕不改源碼能通過補(bǔ)丁解決的絕不直接改文件。補(bǔ)丁至少還能記錄改了什么直接改文件時(shí)間長(zhǎng)了連自己都忘了。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 一個(gè)完整的Autotools項(xiàng)目編譯實(shí)例假設(shè)我們拿到一個(gè)用Autotools構(gòu)建的C語言庫需求是編譯一個(gè)靜態(tài)庫版本去掉調(diào)試符號(hào)安裝到/opt/mylib并且禁用某個(gè)可選功能。第一步解壓源碼并進(jìn)入目錄tar xf mylib-1.2.3.tar.gz cd mylib-1.2.3第二步查看配置選項(xiàng)確認(rèn)禁用功能的參數(shù)名./configure --help | grep -i feature假設(shè)輸出顯示--disable-extra-feature可以關(guān)閉那個(gè)可選功能。第三步執(zhí)行配置./configure \ --prefix/opt/mylib \ --enable-static \ --disable-shared \ --disable-extra-feature \ CFLAGS-O2 -g0這里--enable-static --disable-shared表示只生成靜態(tài)庫CFLAGS-O2 -g0表示優(yōu)化級(jí)別2且不生成調(diào)試符號(hào)。注意CFLAGS是作為環(huán)境變量傳給configure的不是--開頭的選項(xiàng)。第四步編譯并安裝make -j$(nproc) make install如果一切順利/opt/mylib/lib下會(huì)出現(xiàn)libmylib.a/opt/mylib/include下會(huì)出現(xiàn)頭文件。第五步驗(yàn)證產(chǎn)物file /opt/mylib/lib/libmylib.a nm /opt/mylib/lib/libmylib.a | head -20file命令確認(rèn)是靜態(tài)庫歸檔文件nm查看符號(hào)表確認(rèn)關(guān)鍵函數(shù)都在。4.2 一個(gè)CMake項(xiàng)目的定制編譯實(shí)例再來看一個(gè)CMake項(xiàng)目的例子。需求是編譯Release版本使用系統(tǒng)自帶的zlib而不是項(xiàng)目?jī)?nèi)置的開啟測(cè)試構(gòu)建安裝到用戶目錄。第一步創(chuàng)建構(gòu)建目錄CMake推薦out-of-source構(gòu)建mkdir build cd build第二步配置cmake .. \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIX$HOME/opt/myapp \ -DUSE_SYSTEM_ZLIBON \ -DBUILD_TESTINGON第三步編譯cmake --build . -j$(nproc)第四步運(yùn)行測(cè)試如果配置了ctest --output-on-failure第五步安裝cmake --install .CMake項(xiàng)目的一個(gè)好處是配置階段的緩存會(huì)保存在CMakeCache.txt里下次想改某個(gè)選項(xiàng)直接重新跑cmake .. -D新選項(xiàng)值就行不需要從頭來。4.3 交叉編譯的關(guān)鍵配置交叉編譯是源碼編譯里門檻最高的場(chǎng)景之一。核心思路是用本機(jī)的編譯器配合目標(biāo)平臺(tái)的工具鏈和系統(tǒng)庫生成能在目標(biāo)平臺(tái)運(yùn)行的代碼。以給ARM平臺(tái)編譯為例假設(shè)工具鏈前綴是arm-linux-gnueabihf-系統(tǒng)庫根目錄在/opt/arm-sysroot。Autotools項(xiàng)目的配置命令大概長(zhǎng)這樣./configure \ --hostarm-linux-gnueabihf \ --prefix/usr \ --with-sysroot/opt/arm-sysroot \ CCarm-linux-gnueabihf-gcc \ CXXarm-linux-gnueabihf-g \ CFLAGS-O2 --sysroot/opt/arm-sysroot \ LDFLAGS--sysroot/opt/arm-sysrootCMake項(xiàng)目則需要一個(gè)工具鏈文件比如arm-toolchain.cmakeset(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc) set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g) set(CMAKE_SYSROOT /opt/arm-sysroot) set(CMAKE_FIND_ROOT_PATH /opt/arm-sysroot) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)然后配置時(shí)用-DCMAKE_TOOLCHAIN_FILE../arm-toolchain.cmake指定。注意交叉編譯時(shí)最容易出問題的地方是pkg-config。它默認(rèn)會(huì)去找本機(jī)的.pc文件導(dǎo)致鏈接到本機(jī)的庫。解決辦法是設(shè)置PKG_CONFIG_PATH指向sysroot里的pkgconfig目錄或者設(shè)置PKG_CONFIG_SYSROOT_DIR和PKG_CONFIG_LIBDIR環(huán)境變量。4.4 編譯產(chǎn)物的驗(yàn)證與測(cè)試編譯安裝完成不代表萬事大吉驗(yàn)證環(huán)節(jié)不能省。我一般從三個(gè)層面檢查文件層面用file命令確認(rèn)產(chǎn)物架構(gòu)是否正確用ldd查看動(dòng)態(tài)庫依賴是否都能解析用nm或objdump檢查關(guān)鍵符號(hào)是否存在。功能層面跑一遍項(xiàng)目自帶的測(cè)試套件。Autotools項(xiàng)目通常有make checkCMake項(xiàng)目有ctest。如果項(xiàng)目沒有測(cè)試至少寫一個(gè)最小示例程序鏈接編譯出來的庫確認(rèn)能正常調(diào)用。性能層面如果編譯時(shí)做了優(yōu)化定制最好跑一下基準(zhǔn)測(cè)試對(duì)比。比如用-O3 -marchnative編譯的版本跟默認(rèn)-O2版本比性能提升是否達(dá)到預(yù)期。沒有基準(zhǔn)測(cè)試的話至少用time命令跑一個(gè)典型任務(wù)看看耗時(shí)。5. 常見問題與排查技巧實(shí)錄5.1 配置階段報(bào)錯(cuò)排查配置階段的報(bào)錯(cuò)通常比較明確因?yàn)閏onfigure腳本會(huì)輸出它檢測(cè)到了什么、缺了什么。常見的有報(bào)錯(cuò)信息原因解決辦法C compiler cannot create executables編譯器不可用或缺少基礎(chǔ)庫檢查gcc是否安裝gcc -v看能否正常輸出Package xxx was not found缺少依賴庫的開發(fā)包安裝對(duì)應(yīng)的-dev或-devel包c(diǎn)annot find -lxxx鏈接器找不到庫文件確認(rèn)庫已安裝必要時(shí)用LDFLAGS-L/path/to/lib指定路徑error: C17 required編譯器版本過低升級(jí)編譯器或指定更高版本的gconfigure: error: cannot run C compiled programs交叉編譯時(shí)配置錯(cuò)誤檢查--host和工具鏈設(shè)置排查配置錯(cuò)誤的核心方法是看config.log。configure腳本會(huì)把所有檢測(cè)過程的詳細(xì)信息寫進(jìn)這個(gè)文件包括它執(zhí)行了什么命令、得到了什么輸出。報(bào)錯(cuò)信息只是結(jié)論config.log里才有完整的證據(jù)鏈。5.2 編譯階段報(bào)錯(cuò)排查編譯階段的報(bào)錯(cuò)就五花八門了但大致可以歸為幾類頭文件找不到fatal error: xxx.h: No such file or directory。要么是依賴沒裝要么是頭文件路徑?jīng)]傳對(duì)。用find / -name xxx.h 2/dev/null找一下頭文件在哪然后通過CFLAGS-I/path/to/include告訴編譯器。符號(hào)未定義undefined reference to xxx。鏈接階段找不到函數(shù)實(shí)現(xiàn)?？赡苁菐鞗]鏈接也可能是鏈接順序不對(duì)。GCC的鏈接順序是從左到右被依賴的庫要放在依賴它的庫后面。比如-lfoo -lbar如果foo依賴bar這個(gè)順序是對(duì)的反過來就會(huì)報(bào)未定義。編譯器內(nèi)部錯(cuò)誤internal compiler error: Segmentation fault。這種通常是編譯器bug或者資源不足。先降低優(yōu)化級(jí)別和并行數(shù)試試如果還不行就換個(gè)編譯器版本。內(nèi)存不足編譯大型文件時(shí)cc1plus: out of memory。減少并行數(shù)或者給機(jī)器加swap。我遇到過編譯一個(gè)模板展開特別深的C文件單個(gè)文件就吃了8GB內(nèi)存-j1才勉強(qiáng)通過。5.3 安裝與運(yùn)行階段問題安裝階段最常見的問題是權(quán)限不足。make install默認(rèn)往/usr/local寫普通用戶沒權(quán)限。解決辦法是用sudo或者配置階段就指定用戶有權(quán)限的--prefix。運(yùn)行階段的問題更隱蔽。程序編譯鏈接都通過了一運(yùn)行就報(bào)error while loading shared libraries: libxxx.so: cannot open shared object file。這是因?yàn)閯?dòng)態(tài)鏈接器找不到庫文件。解決辦法有三個(gè)把庫路徑加到/etc/ld.so.conf并跑ldconfig設(shè)置LD_LIBRARY_PATH環(huán)境變量或者在編譯時(shí)用-Wl,-rpath/path/to/lib把庫路徑寫進(jìn)可執(zhí)行文件。避坑技巧LD_LIBRARY_PATH是個(gè)雙刃劍用多了容易導(dǎo)致不同程序加載到錯(cuò)誤版本的庫。生產(chǎn)環(huán)境更推薦rpath或者ldconfig方案。我自己在開發(fā)階段會(huì)用LD_LIBRARY_PATH快速驗(yàn)證但最終交付前一定會(huì)改成rpath。5.4 定制編譯的版本管理建議源碼編譯定制最大的隱患是“不可復(fù)現(xiàn)”。今天編譯出來的版本過兩個(gè)月再編譯可能因?yàn)橐蕾嚫?、環(huán)境變化而得到不同的結(jié)果。我的建議是把配置命令寫進(jìn)腳本文件比如build.sh而不是靠記憶敲命令。記錄編譯時(shí)的環(huán)境信息編譯器版本、依賴庫版本、操作系統(tǒng)版本。如果改了源碼用git diff生成補(bǔ)丁文件保存而不是直接改完就完事。對(duì)于需要長(zhǎng)期維護(hù)的定制版本考慮用容器或者虛擬環(huán)境固定構(gòu)建環(huán)境。這些做法看起來麻煩但當(dāng)你需要重新編譯一個(gè)半年前定制的版本時(shí)會(huì)感謝當(dāng)初做了記錄的自己。6. 進(jìn)階定制與性能調(diào)優(yōu)6.1 編譯選項(xiàng)對(duì)性能的實(shí)際影響很多人對(duì)編譯選項(xiàng)的理解停留在“-O3比-O2快”這種模糊認(rèn)知上。實(shí)際測(cè)試下來情況要復(fù)雜得多。我在一個(gè)數(shù)值計(jì)算庫上做過對(duì)比測(cè)試同一份源碼不同編譯選項(xiàng)下的性能差異如下編譯選項(xiàng)相對(duì)性能二進(jìn)制體積編譯時(shí)間-O0基準(zhǔn)最小最短-O2提升約40%中等中等-O3提升約45%較大較長(zhǎng)-O3 -marchnative提升約60%較大較長(zhǎng)-Os提升約20%最小中等可以看到-O2到-O3的邊際收益已經(jīng)很小了但編譯時(shí)間和體積增加明顯。-marchnative帶來的額外提升比較可觀代價(jià)是犧牲了可移植性。所以我的建議是開發(fā)調(diào)試用-O0 -g生產(chǎn)環(huán)境用-O2追求極致性能且不關(guān)心移植性時(shí)用-O3 -marchnative。6.2 鏈接時(shí)優(yōu)化與LTO鏈接時(shí)優(yōu)化Link Time OptimizationLTO是近些年比較受關(guān)注的技術(shù)。傳統(tǒng)編譯模式下每個(gè)源文件獨(dú)立編譯成目標(biāo)文件編譯器看不到跨文件的信息很多優(yōu)化做不了。LTO讓編譯器在鏈接階段還能看到所有目標(biāo)文件的中間表示從而做跨模塊的內(nèi)聯(lián)、常量傳播等優(yōu)化。開啟LTO的方式是在編譯和鏈接選項(xiàng)里都加上-flto。CMake項(xiàng)目可以設(shè)置-DCMAKE_INTERPROCEDURAL_OPTIMIZATIONON。LTO的收益取決于項(xiàng)目結(jié)構(gòu)。對(duì)于大量小函數(shù)分散在多個(gè)文件的項(xiàng)目LTO能帶來明顯的性能提升。但LTO也有代價(jià)編譯鏈接時(shí)間顯著增加內(nèi)存消耗更大而且偶爾會(huì)觸發(fā)編譯器bug。我的經(jīng)驗(yàn)是如果項(xiàng)目本身已經(jīng)做了很好的模塊劃分和頭文件內(nèi)聯(lián)LTO的收益有限如果是那種函數(shù)調(diào)用層次深、跨文件調(diào)用頻繁的項(xiàng)目值得一試。6.3 靜態(tài)分析與安全編譯選項(xiàng)除了性能編譯階段還可以加入安全加固選項(xiàng)?，F(xiàn)代編譯器提供了一系列保護(hù)機(jī)制-fstack-protector-strong棧保護(hù)檢測(cè)棧溢出。-D_FORTIFY_SOURCE2配合-O2使用檢測(cè)緩沖區(qū)溢出。-fPIE -pie生成位置無關(guān)可執(zhí)行文件配合ASLR增強(qiáng)安全性。-Wl,-z,relro -Wl,-z,now立即綁定重定位減少GOT表攻擊面。這些選項(xiàng)在發(fā)行版打包時(shí)通常是默認(rèn)開啟的但自己編譯時(shí)容易被忽略。如果你的程序要對(duì)外提供服務(wù)建議把這些都加上。代價(jià)是輕微的性能損失通常在1%到3%之間換來的是實(shí)實(shí)在在的安全提升。6.4 構(gòu)建緩存與增量編譯大型項(xiàng)目全量編譯一次可能要幾十分鐘甚至幾個(gè)小時(shí)增量編譯和構(gòu)建緩存能大幅提升開發(fā)效率。ccache是最常用的編譯緩存工具。它把編譯結(jié)果按源文件內(nèi)容和編譯選項(xiàng)做哈希緩存下次遇到相同的編譯任務(wù)直接返回緩存結(jié)果。安裝ccache后把CC和CXX指向ccache gcc和ccache g即可。對(duì)于頻繁清理構(gòu)建目錄重新編譯的場(chǎng)景ccache的命中率能到90%以上。CMake項(xiàng)目還可以用ninja替代make作為后端增量編譯的依賴分析更快。配置時(shí)加-G Ninja即可。分布式編譯工具如distcc和icecc能把編譯任務(wù)分發(fā)到多臺(tái)機(jī)器上并行執(zhí)行適合團(tuán)隊(duì)內(nèi)部搭建編譯集群。不過配置和維護(hù)成本較高個(gè)人開發(fā)者一般用不上。7. 源碼定制的邊界與維護(hù)策略7.1 什么該改什么不該改源碼定制最怕的就是改出“孤兒版本”——跟上游完全脫節(jié)既無法合并新功能也無法獲得安全修復(fù)。我的原則是應(yīng)該改的配置選項(xiàng)能覆蓋的定制、通過環(huán)境變量或命令行參數(shù)能調(diào)整的行為、項(xiàng)目明確提供的擴(kuò)展點(diǎn)插件機(jī)制、回調(diào)接口。謹(jǐn)慎改的構(gòu)建腳本中的編譯選項(xiàng)、條件編譯宏的開關(guān)組合、不影響核心邏輯的輔助函數(shù)。盡量不改的核心算法實(shí)現(xiàn)、數(shù)據(jù)結(jié)構(gòu)定義、公共API的簽名。這些改動(dòng)會(huì)像漣漪一樣擴(kuò)散改一處可能影響幾十個(gè)文件。如果確實(shí)需要修改核心代碼最好的方式是向上游提交補(bǔ)丁。這樣你的改動(dòng)會(huì)被納入官方版本后續(xù)升級(jí)時(shí)自動(dòng)包含不需要每次手動(dòng)合并。即使上游不接受至少你有一個(gè)公開的記錄說明改了什么、為什么改。7.2 補(bǔ)丁管理與上游同步對(duì)于必須維護(hù)的定制補(bǔ)丁推薦用git的補(bǔ)丁工作流。基本流程是從上游倉庫克隆一份代碼。在本地分支上做定制修改每個(gè)邏輯獨(dú)立的改動(dòng)單獨(dú)提交。用git format-patch生成補(bǔ)丁文件。上游更新時(shí)git fetch后rebase你的定制分支。這樣做的好處是定制內(nèi)容清晰可查上游更新時(shí)沖突解決有據(jù)可依。如果定制改動(dòng)較多可以考慮維護(hù)一個(gè)長(zhǎng)期分支定期把上游的穩(wěn)定版本合并進(jìn)來。實(shí)操心得補(bǔ)丁要盡量小且聚焦。一個(gè)補(bǔ)丁只做一件事不要在一個(gè)補(bǔ)丁里既改功能又改格式。這樣上游合并時(shí)容易審查沖突時(shí)也容易定位。我見過有人一個(gè)補(bǔ)丁改了三千行包含功能修改、代碼格式化、注釋翻譯這種補(bǔ)丁基本沒法維護(hù)。7.3 構(gòu)建環(huán)境的可復(fù)現(xiàn)性源碼編譯的最終目標(biāo)是得到可復(fù)現(xiàn)的構(gòu)建結(jié)果。同樣的源碼、同樣的配置在任何時(shí)間、任何機(jī)器上編譯都應(yīng)該得到功能一致的產(chǎn)物。實(shí)現(xiàn)可復(fù)現(xiàn)構(gòu)建的幾個(gè)關(guān)鍵點(diǎn)固定編譯器版本不同版本的GCC生成的代碼可能有差異。在項(xiàng)目文檔里明確記錄使用的編譯器版本。固定依賴版本依賴庫的版本更新可能引入行為變化。用包管理器鎖定版本或者把依賴源碼一起納入構(gòu)建。固定構(gòu)建路徑有些構(gòu)建系統(tǒng)會(huì)把構(gòu)建路徑寫進(jìn)產(chǎn)物里導(dǎo)致不同路徑下編譯結(jié)果不同。CMake可以用-DCMAKE_BUILD_RPATH_USE_ORIGINON等選項(xiàng)處理。記錄構(gòu)建元數(shù)據(jù)在產(chǎn)物里嵌入構(gòu)建時(shí)間、Git提交哈希、配置選項(xiàng)摘要等信息方便追溯。這些做法在個(gè)人項(xiàng)目中可能顯得繁瑣但對(duì)于需要長(zhǎng)期維護(hù)或分發(fā)給他人使用的項(xiàng)目是值得投入的基礎(chǔ)設(shè)施。8. 我個(gè)人在源碼編譯定制上的幾條經(jīng)驗(yàn)源碼編譯這件事說到底是“理解系統(tǒng)”的過程。你越了解編譯器、鏈接器、構(gòu)建系統(tǒng)的工作原理遇到問題時(shí)就越從容。我剛開始接觸的時(shí)候遇到報(bào)錯(cuò)就上網(wǎng)搜搜不到就換版本、換參數(shù)瞎試效率極低。后來慢慢養(yǎng)成了看日志、看文檔、看源碼的習(xí)慣才發(fā)現(xiàn)大部分問題的答案其實(shí)就在眼前。另一個(gè)體會(huì)是不要害怕從頭編譯。很多人習(xí)慣了包管理器的一鍵安裝覺得源碼編譯麻煩、容易出錯(cuò)。但實(shí)際上源碼編譯給了你完全的控制權(quán)。你可以精確地知道每個(gè)文件裝到了哪里、每個(gè)功能是開還是關(guān)、每個(gè)優(yōu)化選項(xiàng)是什么。這種掌控感在排查問題時(shí)尤其寶貴。最后說一個(gè)具體的小技巧編譯之前先跑一次make -ndry run看看構(gòu)建系統(tǒng)打算執(zhí)行哪些命令。這個(gè)習(xí)慣幫我發(fā)現(xiàn)過好幾次配置錯(cuò)誤——比如某個(gè)庫的路徑指向了錯(cuò)誤的位置或者某個(gè)編譯選項(xiàng)沒有生效。花幾秒鐘看一眼比編譯到一半報(bào)錯(cuò)再回頭排查要省事得多。