簡介gcc-9.3.0.tar.gz 是 GNU 編譯器套件 9.3.0 版本的官方源碼壓縮包面向需要在 Linux 或類 UNIX 環(huán)境下自行編譯、升級或研究編譯器的開發(fā)者與系統(tǒng)維護(hù)人員。GCC 支持 C、C、Fortran、Ada、Go 等多種語言采用前端與后端分離架構(gòu)可將源碼經(jīng)預(yù)處理、編譯、匯編、鏈接生成目標(biāo)文件并提供多級優(yōu)化選項(xiàng)是軟件開發(fā)與教學(xué)中不可或缺的基礎(chǔ)工具。壓縮包共約 2000 個(gè)文件以 1520 個(gè) c 源文件與 344 個(gè) h 頭文件為主體另含 49 個(gè) pdf 文檔、37 個(gè) cpp、28 個(gè) txt 及少量 sh、py、xml 等腳本與配置整體約 118.39MB覆蓋編譯器核心實(shí)現(xiàn)、語言前端與構(gòu)建腳本。目前已有 352 人學(xué)習(xí)下載。借助該源碼包讀者可深入理解 GCC 的中間表示、優(yōu)化流程與多語言支持機(jī)制并據(jù)此完成本地編譯安裝與版本定制。1. 拿到 gcc-9.3.0.tar.gz 之后為什么源碼編譯不是「解壓即用」很多人第一次拿到gcc-9.3.0.tar.gz這個(gè)包第一反應(yīng)是解壓、./configure、make、make install四連然后等著編譯器自己把自己造出來。結(jié)果往往在make階段卡住兩三個(gè)小時(shí)或者裝完之后gcc --version還是系統(tǒng)自帶的舊版本甚至把系統(tǒng)默認(rèn)編譯器搞壞連yum都跑不起來。這不是玄學(xué)是 GCC 源碼編譯本身的依賴鏈和引導(dǎo)機(jī)制決定的。GCC 是一個(gè)自舉bootstrap編譯器它需要用已有的 C/C 編譯器先編譯出一套自己的中間版本再用這套中間版本編譯出最終版本最后還要用最終版本再編譯一遍自己確認(rèn)三遍結(jié)果一致才算通過。這個(gè)過程對 GMP、MPFR、MPC、ISL 這幾個(gè)數(shù)學(xué)庫的版本極其敏感對 glibc 和 binutils 的版本也有隱性要求。所以gcc-9.3.0.tar.gz不是一個(gè)「下載完就能用」的二進(jìn)制包而是一份需要你補(bǔ)齊前置條件、選對配置參數(shù)、控制好編譯資源才能落地的源碼工程。這篇筆記面向的是需要在特定環(huán)境里固定編譯器版本、又不想動(dòng)系統(tǒng)默認(rèn)工具鏈的工程師從依賴準(zhǔn)備一路寫到驗(yàn)證和排錯(cuò)中間的命令和參數(shù)都可以直接抄。2. 編譯前的依賴賬GMP、MPFR、MPC、ISL 到底怎么配2.1 為什么這四個(gè)庫不能靠系統(tǒng)包管理器隨便裝GCC 在配置階段會檢查 GMP、MPFR、MPC 的版本ISL 則是可選的但強(qiáng)烈建議帶上否則 Graphite 循環(huán)優(yōu)化會缺失。系統(tǒng)自帶的版本往往偏舊比如某些發(fā)行版?zhèn)}庫里的 GMP 還是 6.0.x而 GCC 9.3.0 對 GMP 的最低要求是 4.3.2 以上、MPFR 2.4.2 以上、MPC 0.8.0 以上看起來門檻不高但實(shí)際編譯中如果 GMP 版本過低會在make階段報(bào)出undefined reference to __gmpz_...這類鏈接錯(cuò)誤排查起來很費(fèi)時(shí)間。更穩(wěn)妥的做法是不依賴系統(tǒng)包把這三個(gè)庫的源碼下載下來放在 GCC 源碼目錄同級讓 GCC 的contrib/download_prerequisites腳本自動(dòng)處理或者手動(dòng)指定路徑。我一般會手動(dòng)控制因?yàn)樽詣?dòng)腳本下載的版本和網(wǎng)絡(luò)環(huán)境強(qiáng)相關(guān)一旦中斷就得重來。2.2 手動(dòng)準(zhǔn)備依賴庫的完整命令假設(shè)工作目錄是/opt/build所有源碼都放在這里# 創(chuàng)建工作目錄 mkdir -p /opt/build cd /opt/build # 下載 GCC 9.3.0 源碼假設(shè)已獲得 gcc-9.3.0.tar.gz tar -xf gcc-9.3.0.tar.gz # 下載三個(gè)必需依賴的源碼包版本按 GCC 9.3.0 官方推薦 # gmp-6.1.2, mpfr-4.0.2, mpc-1.1.0 tar -xf gmp-6.1.2.tar.xz tar -xf mpfr-4.0.2.tar.xz tar -xf mpc-1.1.0.tar.gz # 在 GCC 源碼目錄下建立軟鏈接GCC 配置時(shí)會自動(dòng)識別 cd gcc-9.3.0 ln -s ../gmp-6.1.2 gmp ln -s ../mpfr-4.0.2 mpfr ln -s ../mpc-1.1.0 mpc # ISL 可選但建議加上用于 Graphite 優(yōu)化 # 下載 isl-0.18.tar.bz2 后同樣建立軟鏈接 ln -s ../isl-0.18 isl這里的關(guān)鍵點(diǎn)是軟鏈接的名字必須和 GCC 期望的目錄名一致gmp、mpfr、mpc、isl不能寫成gmp-6.1.2這種帶版本號的形式否則配置腳本找不到。軟鏈接建立后GCC 的configure會自動(dòng)進(jìn)入這些目錄編譯依賴不需要你單獨(dú)安裝。2.3 依賴庫版本選擇的參數(shù)說明依賴庫推薦版本最低要求不滿足時(shí)的典型報(bào)錯(cuò)GMP6.1.24.3.2undefined reference to __gmpz_initMPFR4.0.22.4.2mpfr_... not foundMPC1.1.00.8.0mpc_... undeclaredISL0.180.15Graphite 優(yōu)化被禁用不報(bào)錯(cuò)但功能缺失注意如果目標(biāo)機(jī)器是內(nèi)網(wǎng)環(huán)境無法在線下載依賴包需要提前把四個(gè)源碼包傳到本地再建立軟鏈接。不要試圖用系統(tǒng)自帶的舊版本蒙混過關(guān)鏈接階段的報(bào)錯(cuò)信息不會直接告訴你版本不匹配只會給出一堆符號未定義。2.4 系統(tǒng)級工具鏈的最低要求除了這四個(gè)庫還需要確認(rèn)系統(tǒng)里有可用的 C 和 C 編譯器來啟動(dòng)自舉過程。常見做法是用系統(tǒng)自帶的gcc和g版本不低于 4.8 即可。另外make版本建議 3.80 以上binutils里的as和ld也要存在?？梢杂孟旅婷羁焖贆z查gcc --version | head -1 g --version | head -1 make --version | head -1 ld --version | head -1如果系統(tǒng)里連 C 編譯器都沒有需要先通過包管理器安裝gcc-c或build-essential否則配置階段會直接報(bào)C compiler missing。3. 配置與編譯參數(shù)怎么設(shè)、資源怎么控、時(shí)間怎么估3.1 configure 階段必須顯式指定的幾個(gè)開關(guān)GCC 的configure腳本參數(shù)很多但真正影響落地效果的就這么幾個(gè)。我一般會在 GCC 源碼同級建一個(gè)build目錄做 out-of-tree 編譯避免污染源碼樹cd /opt/build mkdir build cd build ../gcc-9.3.0/configure \ --prefix/opt/gcc-9.3.0 \ --enable-languagesc,c,fortran \ --disable-multilib \ --with-system-zlib \ --enable-checkingrelease \ --disable-bootstrap \ --program-suffix-9.3.0逐項(xiàng)說明--prefix/opt/gcc-9.3.0安裝路徑不要裝到/usr否則會和系統(tǒng)默認(rèn)編譯器沖突。--enable-languagesc,c,fortran按需選擇只寫你真正要用的語言減少編譯時(shí)間。不需要 Fortran 就去掉。--disable-multilib只編譯 64 位版本除非你確實(shí)需要 32 位兼容庫否則開著會多花一倍時(shí)間。--with-system-zlib使用系統(tǒng) zlib避免再編譯一份。--enable-checkingrelease關(guān)閉內(nèi)部斷言檢查編譯更快產(chǎn)出的編譯器性能也更好。調(diào)試 GCC 本身時(shí)才用yes或all。--disable-bootstrap跳過三階段自舉只編譯一遍。這是最大的時(shí)間節(jié)省開關(guān)代價(jià)是少了自舉驗(yàn)證。如果你只是要一個(gè)能用的編譯器不是要驗(yàn)證 GCC 自身正確性這個(gè)開關(guān)值得開。--program-suffix-9.3.0給生成的可執(zhí)行文件加后綴比如gcc-9.3.0、g-9.3.0這樣和系統(tǒng)自帶的gcc完全隔離不會互相覆蓋。3.2 make 階段的并行度與內(nèi)存控制配置完成后make是耗時(shí)最長的環(huán)節(jié)。并行度不是越高越好GCC 編譯單個(gè)文件時(shí)內(nèi)存占用可能超過 1GB并行度過高會導(dǎo)致 OOM# 查看 CPU 核心數(shù)和可用內(nèi)存 nproc free -h # 根據(jù)內(nèi)存決定并行度每 2GB 內(nèi)存對應(yīng) 1 個(gè)并行任務(wù) # 假設(shè) 8 核 16GB 內(nèi)存可以用 -j8 make -j8 # 如果內(nèi)存緊張降到 -j4 甚至 -j2 # make -j4一個(gè)經(jīng)驗(yàn)公式并行度 min(CPU核心數(shù), 可用內(nèi)存GB / 2)。比如 4 核 8GB 內(nèi)存用-j4比較穩(wěn)16 核 32GB 內(nèi)存可以用-j16。如果編譯過程中看到virtual memory exhausted或進(jìn)程被 killed就是并行度太高了降下來重新make即可已經(jīng)編譯好的目標(biāo)文件不會丟失。編譯時(shí)間參考--disable-bootstrap且只開 c,c 的情況下8 核機(jī)器大約 20 到 40 分鐘如果開啟 bootstrap時(shí)間翻三倍以上可能超過兩小時(shí)。3.3 安裝與多版本共存的環(huán)境變量配置編譯完成后執(zhí)行安裝make install # 驗(yàn)證安裝結(jié)果 /opt/gcc-9.3.0/bin/gcc-9.3.0 --version /opt/gcc-9.3.0/bin/g-9.3.0 --version如果要在當(dāng)前 shell 里優(yōu)先使用新編譯器把路徑加到PATH前面export PATH/opt/gcc-9.3.0/bin:$PATH export LD_LIBRARY_PATH/opt/gcc-9.3.0/lib64:$LD_LIBRARY_PATH注意LD_LIBRARY_PATH這一行很關(guān)鍵。GCC 9.3.0 編譯出的程序可能依賴它自帶的libstdc.so.6如果系統(tǒng)里舊版本的這個(gè)庫先被找到運(yùn)行時(shí)會報(bào)GLIBCXX_3.4.26 not found。把新庫路徑加到LD_LIBRARY_PATH最前面可以避免這個(gè)問題。但不要寫進(jìn)/etc/ld.so.conf全局生效否則可能影響系統(tǒng)其他程序。如果只是臨時(shí)用一下不想改環(huán)境變量可以直接用絕對路徑調(diào)用/opt/gcc-9.3.0/bin/gcc-9.3.0。在 Makefile 里也可以通過CC和CXX變量指定。4. 避坑與排查五個(gè)讓編譯中途翻車的典型場景4.1 報(bào)錯(cuò)cannot find crti.o或cannot find -lc現(xiàn)象配置階段或鏈接階段提示找不到crti.o、crtn.o或-lc。原因系統(tǒng)缺少 32 位開發(fā)庫或者--disable-multilib沒有生效GCC 仍然嘗試鏈接 32 位目標(biāo)。也可能是LIBRARY_PATH被污染指向了不存在的目錄。解決確認(rèn)--disable-multilib已經(jīng)加上檢查系統(tǒng)是否安裝了glibc-devel或?qū)?yīng)發(fā)行版的開發(fā)包用echo $LIBRARY_PATH查看是否有異常路徑臨時(shí)unset LIBRARY_PATH再重新配置。4.2 編譯到一半提示virtual memory exhausted: Cannot allocate memory現(xiàn)象make進(jìn)行到某個(gè)文件時(shí)進(jìn)程被 killed終端輸出virtual memory exhausted或Killed。原因并行度太高同時(shí)編譯多個(gè)大文件導(dǎo)致內(nèi)存耗盡。GCC 的insn-emit.c、insn-attrtab.c這幾個(gè)文件編譯時(shí)內(nèi)存占用尤其大。解決降低-j數(shù)值比如從-j8降到-j4或-j2如果單文件仍然 OOM可以單獨(dú)用make -j1編譯那個(gè)文件或者臨時(shí)增加 swap 空間。已經(jīng)編譯完成的目標(biāo)文件不會丟失重新make會從斷點(diǎn)繼續(xù)。4.3 安裝后gcc --version仍然顯示舊版本現(xiàn)象make install成功但直接敲gcc --version還是系統(tǒng)舊版本。原因PATH里/usr/bin排在/opt/gcc-9.3.0/bin前面shell 優(yōu)先找到了系統(tǒng)自帶的gcc?；蛘甙惭b時(shí)沒有加--program-suffix新編譯的gcc被裝到了/opt/gcc-9.3.0/bin/gcc但PATH沒更新。解決用which gcc確認(rèn)當(dāng)前找到的是哪個(gè)用export PATH/opt/gcc-9.3.0/bin:$PATH把新路徑提前如果加了--program-suffix-9.3.0直接調(diào)用gcc-9.3.0即可不會和系統(tǒng)gcc沖突。4.4 運(yùn)行編譯出的程序報(bào)GLIBCXX_3.4.26 not found現(xiàn)象用新 GCC 編譯出的 C 程序在運(yùn)行時(shí)報(bào)version GLIBCXX_3.4.26 not found。原因程序鏈接到了 GCC 9.3.0 自帶的libstdc.so.6但運(yùn)行時(shí)系統(tǒng)先找到了舊版本的libstdc.so.6舊版本里沒有GLIBCXX_3.4.26這個(gè)符號版本。解決把/opt/gcc-9.3.0/lib64加到LD_LIBRARY_PATH最前面或者在編譯時(shí)加-static-libstdc靜態(tài)鏈接標(biāo)準(zhǔn)庫或者用-Wl,-rpath,/opt/gcc-9.3.0/lib64把運(yùn)行時(shí)庫路徑寫進(jìn)可執(zhí)行文件。4.5configure階段報(bào)GMP version too old但明明放了新版本現(xiàn)象軟鏈接已經(jīng)建好但configure仍然報(bào) GMP 版本不滿足。原因軟鏈接建在了錯(cuò)誤的目錄層級或者 GCC 源碼目錄下已經(jīng)存在一個(gè)空的gmp目錄導(dǎo)致軟鏈接沒有生效。也可能是configure緩存了上一次的檢測結(jié)果。解決確認(rèn)軟鏈接在gcc-9.3.0/目錄下用ls -l gmp mpfr mpc isl查看鏈接指向如果存在同名空目錄先刪掉再建軟鏈接刪除build目錄下的config.cache重新運(yùn)行configure。5. 驗(yàn)證編譯器是否真的可用三個(gè)測試用例和一個(gè)版本切換技巧裝完編譯器不算完得驗(yàn)證它真的能編譯、能鏈接、能運(yùn)行。我一般用三個(gè)遞進(jìn)的測試用例來確認(rèn)。第一個(gè)是最小 C 程序驗(yàn)證基本編譯和鏈接/* test_c.c */ #include stdio.h int main(void) { printf(gcc-9.3.0 works\n); return 0; }/opt/gcc-9.3.0/bin/gcc-9.3.0 -o test_c test_c.c ./test_c第二個(gè)是 C 程序驗(yàn)證libstdc鏈接和 C17 特性支持// test_cpp.cpp #include iostream #include optional int main() { std::optionalint v 42; std::cout cpp17 optional: *v std::endl; return 0; }/opt/gcc-9.3.0/bin/g-9.3.0 -stdc17 -o test_cpp test_cpp.cpp ./test_cpp第三個(gè)是帶-fopenmp的并行程序驗(yàn)證 OpenMP 運(yùn)行時(shí)庫是否完整/* test_omp.c */ #include omp.h #include stdio.h int main(void) { #pragma omp parallel { int id omp_get_thread_num(); printf(thread %d\n, id); } return 0; }/opt/gcc-9.3.0/bin/gcc-9.3.0 -fopenmp -o test_omp test_omp.c ./test_omp三個(gè)測試都通過說明編譯器、標(biāo)準(zhǔn)庫、OpenMP 運(yùn)行時(shí)都正常。如果第三個(gè)報(bào)libgomp.so.1 not found說明LD_LIBRARY_PATH沒包含/opt/gcc-9.3.0/lib64。關(guān)于多版本切換我習(xí)慣用update-alternatives做系統(tǒng)級管理但更輕量的做法是在項(xiàng)目 Makefile 里直接寫死編譯器路徑CC /opt/gcc-9.3.0/bin/gcc-9.3.0 CXX /opt/gcc-9.3.0/bin/g-9.3.0 CFLAGS -O2 -Wall這樣每個(gè)項(xiàng)目用哪個(gè)編譯器一目了然不會因?yàn)?shell 環(huán)境變化而意外切換。如果確實(shí)需要頻繁切換可以在~/.bashrc里寫兩個(gè)函數(shù)use_gcc9() { export PATH/opt/gcc-9.3.0/bin:$PATH export LD_LIBRARY_PATH/opt/gcc-9.3.0/lib64:$LD_LIBRARY_PATH } use_system_gcc() { export PATH$(echo $PATH | sed s|/opt/gcc-9.3.0/bin:||g) export LD_LIBRARY_PATH$(echo $LD_LIBRARY_PATH | sed s|/opt/gcc-9.3.0/lib64:||g) }最后說一個(gè)我踩過的坑有一次在容器里編譯--prefix設(shè)成了/usr/local裝完之后容器里所有依賴系統(tǒng)gcc的構(gòu)建腳本全部報(bào)錯(cuò)因?yàn)閘ibstdc被替換成了新版本舊程序找不到符號。后來我給自己定了一條規(guī)矩源碼編譯的 GCC 永遠(yuǎn)裝到獨(dú)立前綴永遠(yuǎn)加--program-suffix永遠(yuǎn)不碰系統(tǒng)默認(rèn)路徑。這個(gè)習(xí)慣幫我省下了至少三次重裝系統(tǒng)的后悔藥。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取