简介：gcc-9.3.0.tar.gz 是 GNU 编译器套件 9.3.0 版本的官方源码压缩包，面向需要在 Linux 或类 UNIX 环境下自行编译、升级或研究编译器的开发者与系统维护人员。GCC 支持 C、C++、Fortran、Ada、Go 等多种语言，采用前端与后端分离架构，可将源码经预处理、编译、汇编、链接生成目标文件，并提供多级优化选项，是软件开发与教学中不可或缺的基础工具。压缩包共约 2000 个文件，以 1520 个 c 源文件与 344 个 h 头文件为主体，另含 49 个 pdf 文档、37 个 cpp、28 个 txt 及少量 sh、py、xml 等脚本与配置，整体约 118.39MB，覆盖编译器核心实现、语言前端与构建脚本。目前已有 352 人学习下载。借助该源码包，读者可深入理解 GCC 的中间表示、优化流程与多语言支持机制，并据此完成本地编译安装与版本定制。
1. 拿到 gcc-9.3.0.tar.gz 之后：为什么源码编译不是「解压即用」
很多人第一次拿到gcc-9.3.0.tar.gz这个包，第一反应是解压、./configure、make、make install四连，然后等着编译器自己把自己造出来。结果往往在make阶段卡住两三个小时，或者装完之后gcc --version还是系统自带的旧版本，甚至把系统默认编译器搞坏，连yum都跑不起来。这不是玄学，是 GCC 源码编译本身的依赖链和引导机制决定的。
GCC 是一个自举（bootstrap）编译器：它需要用已有的 C/C++ 编译器先编译出一套自己的中间版本，再用这套中间版本编译出最终版本，最后还要用最终版本再编译一遍自己，确认三遍结果一致才算通过。这个过程对 GMP、MPFR、MPC、ISL 这几个数学库的版本极其敏感，对 glibc 和 binutils 的版本也有隐性要求。所以gcc-9.3.0.tar.gz不是一个「下载完就能用」的二进制包，而是一份需要你补齐前置条件、选对配置参数、控制好编译资源才能落地的源码工程。这篇笔记面向的是需要在特定环境里固定编译器版本、又不想动系统默认工具链的工程师，从依赖准备一路写到验证和排错，中间的命令和参数都可以直接抄。
2. 编译前的依赖账：GMP、MPFR、MPC、ISL 到底怎么配
2.1 为什么这四个库不能靠系统包管理器随便装
GCC 在配置阶段会检查 GMP、MPFR、MPC 的版本，ISL 则是可选的但强烈建议带上，否则 Graphite 循环优化会缺失。系统自带的版本往往偏旧，比如某些发行版仓库里的 GMP 还是 6.0.x，而 GCC 9.3.0 对 GMP 的最低要求是 4.3.2 以上、MPFR 2.4.2 以上、MPC 0.8.0 以上，看起来门槛不高，但实际编译中如果 GMP 版本过低，会在make阶段报出undefined reference to __gmpz_...这类链接错误，排查起来很费时间。
更稳妥的做法是：不依赖系统包，把这三个库的源码下载下来，放在 GCC 源码目录同级，让 GCC 的contrib/download_prerequisites脚本自动处理，或者手动指定路径。我一般会手动控制，因为自动脚本下载的版本和网络环境强相关，一旦中断就得重来。
2.2 手动准备依赖库的完整命令
假设工作目录是/opt/build，所有源码都放在这里：
# 创建工作目录 mkdir -p /opt/build && cd /opt/build # 下载 GCC 9.3.0 源码（假设已获得 gcc-9.3.0.tar.gz） tar -xf gcc-9.3.0.tar.gz # 下载三个必需依赖的源码包（版本按 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 配置时会自动识别 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 优化 # 下载 isl-0.18.tar.bz2 后同样建立软链接 ln -s ../isl-0.18 isl这里的关键点是软链接的名字必须和 GCC 期望的目录名一致：gmp、mpfr、mpc、isl，不能写成gmp-6.1.2这种带版本号的形式，否则配置脚本找不到。软链接建立后，GCC 的configure会自动进入这些目录编译依赖，不需要你单独安装。
2.3 依赖库版本选择的参数说明
| 依赖库 | 推荐版本 | 最低要求 | 不满足时的典型报错 |
|---|---|---|---|
| GMP | 6.1.2 | 4.3.2 | undefined reference to __gmpz_init |
| MPFR | 4.0.2 | 2.4.2 | mpfr_... not found |
| MPC | 1.1.0 | 0.8.0 | mpc_... undeclared |
| ISL | 0.18 | 0.15 | Graphite 优化被禁用，不报错但功能缺失 |
注意：如果目标机器是内网环境，无法在线下载依赖包，需要提前把四个源码包传到本地，再建立软链接。不要试图用系统自带的旧版本蒙混过关，链接阶段的报错信息不会直接告诉你版本不匹配，只会给出一堆符号未定义。
2.4 系统级工具链的最低要求
除了这四个库，还需要确认系统里有可用的 C 和 C++ 编译器来启动自举过程。常见做法是用系统自带的gcc和g++，版本不低于 4.8 即可。另外make版本建议 3.80 以上，binutils里的as和ld也要存在。可以用下面命令快速检查：
gcc --version | head -1 g++ --version | head -1 make --version | head -1 ld --version | head -1如果系统里连 C++ 编译器都没有，需要先通过包管理器安装gcc-c++或build-essential，否则配置阶段会直接报C++ compiler missing。
3. 配置与编译：参数怎么设、资源怎么控、时间怎么估
3.1 configure 阶段必须显式指定的几个开关
GCC 的configure脚本参数很多，但真正影响落地效果的就这么几个。我一般会在 GCC 源码同级建一个build目录，做 out-of-tree 编译，避免污染源码树：
cd /opt/build mkdir build && cd build ../gcc-9.3.0/configure \ --prefix=/opt/gcc-9.3.0 \ --enable-languages=c,c++,fortran \ --disable-multilib \ --with-system-zlib \ --enable-checking=release \ --disable-bootstrap \ --program-suffix=-9.3.0逐项说明：
--prefix=/opt/gcc-9.3.0：安装路径，不要装到/usr，否则会和系统默认编译器冲突。--enable-languages=c,c++,fortran：按需选择，只写你真正要用的语言，减少编译时间。不需要 Fortran 就去掉。--disable-multilib：只编译 64 位版本，除非你确实需要 32 位兼容库，否则开着会多花一倍时间。--with-system-zlib：使用系统 zlib，避免再编译一份。--enable-checking=release：关闭内部断言检查，编译更快，产出的编译器性能也更好。调试 GCC 本身时才用yes或all。--disable-bootstrap：跳过三阶段自举，只编译一遍。这是最大的时间节省开关，代价是少了自举验证。如果你只是要一个能用的编译器，不是要验证 GCC 自身正确性，这个开关值得开。--program-suffix=-9.3.0：给生成的可执行文件加后缀，比如gcc-9.3.0、g++-9.3.0，这样和系统自带的gcc完全隔离，不会互相覆盖。
3.2 make 阶段的并行度与内存控制
配置完成后，make是耗时最长的环节。并行度不是越高越好，GCC 编译单个文件时内存占用可能超过 1GB，并行度过高会导致 OOM：
# 查看 CPU 核心数和可用内存 nproc free -h # 根据内存决定并行度：每 2GB 内存对应 1 个并行任务 # 假设 8 核 16GB 内存，可以用 -j8 make -j8 # 如果内存紧张，降到 -j4 甚至 -j2 # make -j4一个经验公式：并行度 = min(CPU核心数, 可用内存GB / 2)。比如 4 核 8GB 内存，用-j4比较稳；16 核 32GB 内存，可以用-j16。如果编译过程中看到virtual memory exhausted或进程被 killed，就是并行度太高了，降下来重新make即可，已经编译好的目标文件不会丢失。
编译时间参考：--disable-bootstrap且只开 c,c++ 的情况下，8 核机器大约 20 到 40 分钟；如果开启 bootstrap，时间翻三倍以上，可能超过两小时。
3.3 安装与多版本共存的环境变量配置
编译完成后执行安装：
make install # 验证安装结果 /opt/gcc-9.3.0/bin/gcc-9.3.0 --version /opt/gcc-9.3.0/bin/g++-9.3.0 --version如果要在当前 shell 里优先使用新编译器，把路径加到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这一行很关键。GCC 9.3.0 编译出的程序可能依赖它自带的libstdc++.so.6，如果系统里旧版本的这个库先被找到，运行时会报GLIBCXX_3.4.26 not found。把新库路径加到LD_LIBRARY_PATH最前面可以避免这个问题。但不要写进/etc/ld.so.conf全局生效，否则可能影响系统其他程序。
如果只是临时用一下，不想改环境变量，可以直接用绝对路径调用：/opt/gcc-9.3.0/bin/gcc-9.3.0。在 Makefile 里也可以通过CC和CXX变量指定。
4. 避坑与排查：五个让编译中途翻车的典型场景
4.1 报错cannot find crti.o或cannot find -lc
现象：配置阶段或链接阶段提示找不到crti.o、crtn.o或-lc。
原因：系统缺少 32 位开发库，或者--disable-multilib没有生效，GCC 仍然尝试链接 32 位目标。也可能是LIBRARY_PATH被污染，指向了不存在的目录。
解决：确认--disable-multilib已经加上；检查系统是否安装了glibc-devel（或对应发行版的开发包）；用echo $LIBRARY_PATH查看是否有异常路径，临时unset LIBRARY_PATH再重新配置。
4.2 编译到一半提示virtual memory exhausted: Cannot allocate memory
现象：make进行到某个文件时进程被 killed，终端输出virtual memory exhausted或Killed。
原因：并行度太高，同时编译多个大文件导致内存耗尽。GCC 的insn-emit.c、insn-attrtab.c这几个文件编译时内存占用尤其大。
解决：降低-j数值，比如从-j8降到-j4或-j2；如果单文件仍然 OOM，可以单独用make -j1编译那个文件，或者临时增加 swap 空间。已经编译完成的目标文件不会丢失，重新make会从断点继续。
4.3 安装后gcc --version仍然显示旧版本
现象：make install成功，但直接敲gcc --version还是系统旧版本。
原因：PATH里/usr/bin排在/opt/gcc-9.3.0/bin前面，shell 优先找到了系统自带的gcc。或者安装时没有加--program-suffix，新编译的gcc被装到了/opt/gcc-9.3.0/bin/gcc，但PATH没更新。
解决：用which gcc确认当前找到的是哪个；用export PATH=/opt/gcc-9.3.0/bin:$PATH把新路径提前；如果加了--program-suffix=-9.3.0，直接调用gcc-9.3.0即可，不会和系统gcc冲突。
4.4 运行编译出的程序报GLIBCXX_3.4.26 not found
现象：用新 GCC 编译出的 C++ 程序在运行时报version 'GLIBCXX_3.4.26' not found。
原因：程序链接到了 GCC 9.3.0 自带的libstdc++.so.6，但运行时系统先找到了旧版本的libstdc++.so.6，旧版本里没有GLIBCXX_3.4.26这个符号版本。
解决：把/opt/gcc-9.3.0/lib64加到LD_LIBRARY_PATH最前面；或者在编译时加-static-libstdc++静态链接标准库；或者用-Wl,-rpath,/opt/gcc-9.3.0/lib64把运行时库路径写进可执行文件。
4.5configure阶段报GMP version too old但明明放了新版本
现象：软链接已经建好，但configure仍然报 GMP 版本不满足。
原因：软链接建在了错误的目录层级，或者 GCC 源码目录下已经存在一个空的gmp目录，导致软链接没有生效。也可能是configure缓存了上一次的检测结果。
解决：确认软链接在gcc-9.3.0/目录下，用ls -l gmp mpfr mpc isl查看链接指向；如果存在同名空目录，先删掉再建软链接；删除build目录下的config.cache，重新运行configure。
5. 验证编译器是否真的可用：三个测试用例和一个版本切换技巧
装完编译器不算完，得验证它真的能编译、能链接、能运行。我一般用三个递进的测试用例来确认。
第一个是最小 C 程序，验证基本编译和链接：
/* 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第二个是 C++ 程序，验证libstdc++链接和 C++17 特性支持：
// test_cpp.cpp #include <iostream> #include <optional> int main() { std::optional<int> v = 42; std::cout << "cpp17 optional: " << *v << std::endl; return 0; }/opt/gcc-9.3.0/bin/g++-9.3.0 -std=c++17 -o test_cpp test_cpp.cpp ./test_cpp第三个是带-fopenmp的并行程序，验证 OpenMP 运行时库是否完整：
/* 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三个测试都通过，说明编译器、标准库、OpenMP 运行时都正常。如果第三个报libgomp.so.1 not found，说明LD_LIBRARY_PATH没包含/opt/gcc-9.3.0/lib64。
关于多版本切换，我习惯用update-alternatives做系统级管理，但更轻量的做法是在项目 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这样每个项目用哪个编译器一目了然，不会因为 shell 环境变化而意外切换。如果确实需要频繁切换，可以在~/.bashrc里写两个函数：
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') }最后说一个我踩过的坑：有一次在容器里编译，--prefix设成了/usr/local，装完之后容器里所有依赖系统gcc的构建脚本全部报错，因为libstdc++被替换成了新版本，旧程序找不到符号。后来我给自己定了一条规矩：源码编译的 GCC 永远装到独立前缀，永远加--program-suffix，永远不碰系统默认路径。这个习惯帮我省下了至少三次重装系统的后悔药。希望帮到你。
本文还有配套的精品资源，点击获取
