GCC 9.5.0源码编译实战：彻底解决gcc/g++版本不对

简介gcc-9.5.0.tar.gz是GNU编译器集合9.5.0版本的完整源码压缩包面向Linux/Unix系统开发者、编译器研究者和需要从源码构建GCC环境的用户。包内主要包含C、C、Objective-C、Fortran等语言前端与后端实现以及configure配置脚本、构建和安装工具便于按需定制编译选项。压缩包整体约122.2MB结构上仅有gcc-9.5.0单一目录核心源码与构建脚手架均位于其中适合作为纯净基础版本进行二次开发或学习。目前已有170人学习下载。通过阅读和编译这份源码开发者可深入理解编译器工作流程掌握前端词法/语法分析、后端代码生成等关键机制并能针对特定架构优化或扩展语言特性是研究编译器技术与参与开源生态的优质素材。1. 为什么要自己编译 gcc-9.5.0.tar.gz一次源码编译解决 gcc g 版本不对当你发现 Ubuntu 里 apt 安装 gcc 持续失败或者项目要求 C17 但系统编译器还停在 4.8.5手头这份 gcc-9.5.0.tar.gz 就是最直接的解法。它把 GCC 9 系列的最终补丁版本全部源码放在一个干净的顶层目录里适合系统 gcc 太旧、不想动系统环境的应用开发者也适合正在研究 configure 和 make 到底做了什么的人。我见过太多人升级 gcc 之后gcc --version还是旧版本或者编译到一半被killed其实问清楚「自己编了什么、装到了哪个前缀」就能避开一大半问题。下面按源码包检查、configure、make、安装验证、常见坑的顺序写。2. 先把源码包看明白gcc-9.5.0.tar.gz 的版本含义、解压前的检查与目录结构2.1 9.5.0 这个版本号怎么读和 GCC 9 系列其他小版本差在哪GCC 的版本号由主版本、次版本、修订号组成9.5.0表示 9 主系列的第 5 个修订版。主版本号决定语言标准和后端优化框架的基础次版本和修订号则是在此之上修 bug、补特性。比如 GCC 9.5.0 相比同系列的 9.3.0修复了若干-O2下代码生成的回归问题也补了 C 标准库的一些边界场景。对生产环境来说同主版本内尽量选最后一个修订版因为编译器本身是个黑匣子能少踩一个已修复的 bug 就少踩一个。如果你只是想让老项目在低版本内核上编译9.5.0 比 GCC 10、11 更友好。它要求的 binutils 和 glibc 最低版本更低在 CentOS 7、Rocky Linux、Kylin V10 这类系统上 configure 更容易通过。这也是我坚持在源码包里选这个版本而不是追新的原因编译 gcc 12 的依赖门槛更高通常需要先把 9.5.0 这一套依赖环境打通再谈升级。关于 gcc 和 g 的关系这里多说一句g 不是另一个独立的编译器它是 GCC 套件里针对 C 的命令行前端内部调用 cc1plus 和 collect2。所以你在 configure 时只要--enable-languagesc,c安装完成后 gcc 和 g 会同时出现在 bin 目录里不需要单独再下一个 g 包。标题关键词里「gcc g 源码」指的就是这套同源关系。2.2 解压前先做四件事校验文件、看磁盘、看系统 gcc、确认依赖源码包没有附带下载信息的场景里第一步不是急着解压而是先确认压缩包本身没坏。常见做法是用tar -tzf读一遍压缩包文件列表把输出重定向到/dev/null。如果 gzip 流损坏tar 会直接报错所以这条命令能快速判断包是否可读。tar -tzf gcc-9.5.0.tar.gz /dev/null echo archive OK df -h /tmp /usr/local gcc --version 2/dev/null || echo no gcctar -tzf是列出包内文件但不解压轻量验证压缩包完整df -h看/tmp和/usr/local的剩余空间GCC 源码编译后大约要占 4 到 8 GB如果--prefix放在/usr/local/gcc-9.5.0那这个分区必须有足够余量gcc --version是确认系统当前有没有编译器因为源码编译 GCC 需要先有一个能用的 C 编译器作为引导。如果你在 Ubuntu 上连系统 gcc 都没有先apt install build-essential否则 configure 会在检查 bootstrap 工具链时直接退出。下一步是检查内存和 CPU 核数这直接决定后面make -j开多少线程。GCC 编译过程非常吃内存我在 8 GB 内存的 VPS 上开过-j4结果编译到一半进程被 OOM killer 杀掉白白等了四十分钟。nproc free -hnproc返回逻辑核数free -h看可用内存。如果机器只有 2 核、4 GB 内存后面用make -j2不要盲目开-j4如果内存超过 8 GBmake -j$(nproc)通常问题不大但也要像第 4 章那样保留一份编译日志方便出问题时定位。这里还要注意一个细节/tmp在很多系统上是 tmpfs大小等于物理内存的一半左右不要把源码包解压到/tmp之后发现磁盘突然满了那是内存映射分区不是真实磁盘空间。最后解压之前确认系统里有没有 GMP、MPFR、MPC 三个依赖库的开发包。不同发行版包名不一样Debian/Ubuntu 用libgmp-dev、libmpfr-dev、libmpc-devRocky/CentOS 用gmp-devel、mpfr-devel、libmpc-devel。这里先不立即安装等 configure 报错再补也来得及但提前装能少翻一次车。sudo apt-get install -y libgmp-dev libmpfr-dev libmpc-dev这是 Ubuntu 系的一行命令Rocky 系换成sudo yum install -y gmp-devel mpfr-devel libmpc-devel。如果你下载 gcc 网速过慢先把源码包放到本地之后 configure、make 都可以离线完成但依赖库得提前准备好因为contrib/download_prerequisites脚本默认从网络拉源码离线环境下没法用。2.3 解压以后先逛目录configure、contrib、gcc/doc 分别有什么用确认没问题之后再解压tar -xzf gcc-9.5.0.tar.gz cd gcc-9.5.0 ls -F | head -30ls -F会标注目录和可执行文件你会看到configure、contrib/、gcc/、libstdc-v3/这些核心目录。压缩包里只有一个顶层目录gcc-9.5.0解压后不会把文件散落到当前目录这是个很干净的结构如果你在容器或私有仓库场景要用这个包最好保留 tar.gz 原格式分发解压后再打成 tar.gz 容易破坏符号链接和可执行位。我的习惯是解压后先看三个地方。contrib/download_prerequisites是 GCC 官方提供的脚本运行它会自动下载并解压 GMP、MPFR、MPC 到源码树内避免手动对版本号缺点是要联网离线环境只能放弃。gcc/doc/目录下有大量.texi和.info文件那是完整的 GCC 文档源码编译安装后通过info gcc能读同一份说明。configure是接下来所有工作的入口它本质上是生成 Makefile 的 shell 脚本参数主要影响三件事装到哪里--prefix、编译哪些语言前端--enable-languages、是否支持多架构库--enable-multilib/--disable-multilib。这些参数不是玄学每一个都对应具体的构建行为下一章我把常用组合写出来。这里也要强调一句解压后不要急着删源码目录而且我建议建一个独立构建目录做 out-of-source 构建。这样源码树保持干净同一个源码包可以配置出多份不同的编译结果以后想再编一个 32 位版本或者其他语言前端不需要重新解压。3. configure 决定命运GCC 源码编译里最容易出错的参数与依赖组合3.1 先装依赖还是先 configuregmp/mpfr/mpc 的常见处理方式很多第一次编 GCC 的人都会在 configure 阶段看到类似Building GCC requires GMP 4.2, MPFR 3.1.0 and MPC 0.8.0的报错。这个报错信息很直白GCC 的中间表示、浮点常量折叠和树优化都依赖这三个库它们不在系统默认的头文件和库搜索路径里configure 检查就会被判失败。处理方式有两种。第一种是直接用发行版仓库安装开发包这是最省事的路径sudo apt-get install -y libgmp-dev libmpfr-dev libmpc-dev装完以后重新运行 configure 通常就过了。需要留意包名Ubuntu 上叫libmpc-dev不是mpcCentOS/Rocky 上叫libmpc-devel。如果你已经装了还报缺失多半是头文件或库文件在/usr/local/lib而不是默认路径那就要在 configure 时显式指定--with-gmp-include和--with-gmp-lib这个场景放到第 5 章避坑部分细说。第二种是运行源码树自带的脚本让 GCC 自己把依赖带进来./contrib/download_prerequisites这个脚本会把对应版本的 GMP、MPFR、MPC 下载解压到当前目录编译时由 GCC 的构建系统统一处理。用它的好处是不用关心系统包管理器的版本差异坏处是必须能访问 GNU 镜像如果你下载 gcc 网速过慢这一步可能比编译本身还折磨。我的做法是能装系统包就装系统包离线环境下再考虑脚本如果公司内网有镜像同步也可以通过环境变量改下载源但那属于基础设施的活儿一般开发者不用碰。3.2 参数怎么给--prefix、--enable-languages、--disable-multilib、--build 的取舍configure 参数决定了后续所有行为我把最常用的几个列成表后面命令都按这个表理解。参数含义我的建议--prefix/usr/local/gcc-9.5.0安装根目录一定设独立目录别用默认/usr/local否则容易和系统 gcc 混在一起--enable-languagesc,c启用哪些语言前端只编 c 和 cgcc、g 都覆盖Fortran/Ada 不编能省很多时间--disable-multilib不编译 32 位额外库64 位系统默认建议关闭依赖更少--buildx86_64-linux-gnu指定构建主机三元组通常不写也行configure 会自动检测写错会引发找不到头文件的错误--disable-bootstrap不做三次自举编译首次尝试可以加能省一半时间追求长期稳定不要加--prefix是最值得花心思的参数。如果直接用系统默认/usr/local/bin/gcc你的自编译版本会和发行版的 gcc 抢bin、lib、include目录哪天系统包管理器升级就把你覆盖了。设成/usr/local/gcc-9.5.0之后所有二进制都集中在这个目录里验证失败时直接删目录就恢复原状也算是一剂后悔药。--enable-languages大而全会让编译时间变成原来的几倍。GCC 8 之后的源码里 Fortran、Ada、Go 前端的构建都很重如果只是写 C/Cc,c是最有性价比的组合。这里再说一次g 不是独立编译器只要前端启用cg 就会生成。--disable-bootstrap是我在第一次尝试时的默认选择。bootstrap 会先编出一个 stage1 编译器再用这个编译器重新编译 GCC 源码最后用 stage2 的结果再编一次整个过程相当于三遍 make时间非常长。反过来用系统 gcc 直接编一遍出成品适合先打通流程等你确定要长期使用这个编译器再做一次完整 bootstrap 构建那个产物在优化效果上确实更好。如果日志里出现bootstrap comparison failure多半是内存不稳或编译器自身问题加--disable-bootstrap能绕开但生产环境不建议这么干。3.3 一个实际可复制的 configure 命令与它的执行输出把上面的参数串起来我一般这样执行cd gcc-9.5.0 mkdir -p ../gcc-9.5.0-build cd ../gcc-9.5.0-build ../gcc-9.5.0/configure \ --prefix/usr/local/gcc-9.5.0 \ --enable-languagesc,c \ --disable-multilib \ --disable-bootstrap \ --buildx86_64-linux-gnu在独立的 build 目录里运行 configure是为了避免源码目录里混入生成的 Makefile 和中间产物。configure 输出的最后几行会给出配置摘要比如Configuration is: x86_64-linux-gnu和Configured with: ...这说明参数解析成功。如果你看到error: something required is missing先别急着改参数按第 5 章排查顺序走一遍更快。configure 失败的时候不要一遍遍反复跑同样的命令。常见做法是打开config.log直接看最后几十行tail -n 80 config.logconfig.log是 configure 自己生成的诊断文件里面不但有报错原因还有 gcc 在检查某个头文件或链接库时的完整命令很多时候问题不是出在你写的参数上而是系统缺少具体的-dev包看日志比猜参数高效得多。configure 成功后会生成 Makefile这时可以用grep ^prefix Makefile确认安装路径没写错。很多人在这里掉进坑configure 全部通过但 make install 装到了/usr/local/bin就是因为--prefix没设置或写错了路径。4. 编译与安装make -j 加速、日志怎么留、安装后为什么还是旧版本4.1 make 的并行度、swap 和 OOM 的关系configure 通过后真正的耗时在 make 阶段。源码编译 GCC 9.5.0 在四核机器上通常要 30 分钟到 1 小时单线程则可能超过 2 小时所以并行度设置直接影响体验但也别把内存撑爆。我的习惯是这样make -j2 21 | tee /tmp/gcc-make.log-j2表示同时跑两个编译任务如果你内存足够16 GB 以上可以改成-j$(nproc)。21 | tee的作用是把标准输出和标准错误一起写进/tmp/gcc-make.log同时屏幕上还能看到进度这就是把 GCC 编译日志输出到文件的常用做法。日志很重要因为 OOM 出现时终端滚动早就把源头冲掉了回看日志才能确定是哪个.s文件没编过去。为什么说内存和并行度相关GCC 的 C 前端在解析模板和生成 RTL 时单进程就能吃掉 1 到 2 GB-j4同时四个进程就是 8 GB。我在 8 GB 内存的 VPS 上开过-j4结果编译到一半进程被 killeddmesg里出现Out of memory那会儿还没有任何报错文本。所以编译大型工具链我会先free -h再决定-j。如果内存确实不够加 swap 是有效办法。Linux 下用文件做临时 swap 很常见sudo fallocate -l 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfilefallocate预分配 8 GB 文件chmod 600避免其他用户读写mkswap把它格式化为交换分区swapon立即启用。这样即使内存不够编译进程也能靠 swap 继续走完不会直接被杀。不过这只是应急长时间编译还是优先调低-jswap 在机械盘上会让编译过程明显变慢属于用时间换安全。编译过程中可以另开一个终端用top或free持续观察内存占用。如果看到 cc1plus 进程一个个被杀马上 Ctrl-C 终止 make调低并行度后重新跑make 会复用已经生成的.o不会从头再来所以不用担心前功尽弃。4.2 make install 以后为什么 gcc --version 没变PATH 与符号链接make 完成后make install会把二进制复制到--prefix目录。很多人做完这一步兴冲冲执行gcc --version结果看到的还是/usr/bin/gcc的旧版本。这个问题在搜索引擎里高频出现因为它不是编译失败而是环境变量优先级的问题。先看自己编译的 gcc 到底在哪/usr/local/gcc-9.5.0/bin/gcc --version如果它正常输出gcc (GCC) 9.5.0说明编译安装已经成功。此时系统找不到新版本是因为/usr/local/gcc-9.5.0/bin不在 PATH或者它排在/usr/bin后面。解决方法是把新目录插到 PATH 最前面export PATH/usr/local/gcc-9.5.0/bin:$PATH这条命令只对当前 shell 有效想永久生效要写进~/.bashrc或~/.profile。我一般会写一行小命令进去printf export PATH/usr/local/gcc-9.5.0/bin:$PATH\n ~/.bashrc source ~/.bashrcprintf把完整的 export 行追加到.bashrc末尾source让当前 shell 立即读取新配置。这里有一个容易忽略的点如果你是在 tmux 或已打开的终端里做的旧 shell 不会自动拿到新 PATH必须重新开窗口或者 source 一次。更严格的验证不是只看gcc --version还要看符号链接readlink -f $(which gcc)如果你的which gcc返回/usr/local/gcc-9.5.0/bin/gccreadlink又指向真实二进制那才是真的切换成功。如果返回的还是/usr/bin/gcc说明/usr/bin在你的 PATH 里优先级更高检查一下是不是在设置 PATH 的语句之前做了 export或者/etc/profile里又重置了 PATH。4.3 验证自编译的 gcc 和 g 是否真的生效版本号只是表面真正要验证的是 gcc 和 g 能否正常编译并运行程序。我习惯写一个最小 demo 跑一遍echo int main(){return 0;} | gcc -x c - -o /tmp/tc /tmp/tc echo c ok echo int main(){return 0;} | g -x c - -o /tmp/tcpp /tmp/tcpp echo c ok-x c是告诉编译器输入来自标准输入且按 C 语言处理-x c同理-o指定输出文件名串联保证每一步成功才继续。这两个命令能过说明新工具链至少能完成从源码到可执行文件的完整流程。还要注意动态库版本。GCC 9 生成的 C 程序运行时需要libstdc.so.6如果编译时用新 g运行时出现error while loading shared libraries: libstdc.so.6一般是动态链接器找不到/usr/local/gcc-9.5.0/lib64。这时可以临时设置export LD_LIBRARY_PATH/usr/local/gcc-9.5.0/lib64:$LD_LIBRARY_PATH这个变量让动态链接器去新路径找libstdc.so.6。如果不想每次 export可以用-Wl,-rpath,/usr/local/gcc-9.5.0/lib64把路径编进可执行文件里但那样会让可执行文件带有绝对路径部署到其他机器时要小心。熟手通常还会用/usr/local/gcc-9.5.0/bin/g -v查看编译器的配置参数确认Configured with里的--prefix与预期一致这一步能发现很多隐蔽的路径问题。5. 避坑 / 常见问题从 configure 失败到 libstdc 缺失的五个现场实际配置里我很少第一次就成功以下五个现场基本覆盖了从下载 tar.gz 到最终gcc --version的常见翻车点。每条都按现象、原因、解决写的你可以直接对照自己的报错。5.1 configure 报错找不到 GMP/MPFR/MPC但系统明明装了现象运行 configure 后直接退到 shell最后一行是configure: error: Building GCC requires GMP 4.2, MPFR 3.1.0 and MPC 0.8.0。可是我明明用apt list --installed看到了libgmp-dev。原因头文件和库文件的路径不在 GCC configure 的默认搜索目录里。Ubuntu 的 64 位库常装在/usr/lib/x86_64-linux-gnu如果系统同时存在 32 位版本的 libgmp或者你自己把 GMP 编译安装到了/usr/localconfigure 可能会找到 ABI 不匹配的库导致检查失败。解决先确认开发包确实存在用ls -l /usr/include/x86_64-linux-gnu/gmp.h看一眼。如果头文件缺失说明只装了运行时库libgmp10没装libgmp-dev。如果头文件在但 configure 还是报错多半是路径特殊显式指定../gcc-9.5.0/configure \ --prefix/usr/local/gcc-9.5.0 \ --with-gmp-include/usr/include/x86_64-linux-gnu \ --with-gmp-lib/usr/lib/x86_64-linux-gnu \ --with-mpfr-include/usr/include/x86_64-linux-gnu \ --with-mpfr-lib/usr/lib/x86_64-linux-gnu \ --with-mpc-include/usr/include/x86_64-linux-gnu \ --with-mpc-lib/usr/lib/x86_64-linux-gnu--with-xxx-include和--with-xxx-lib分别是告诉 configure 去哪里找头文件和库文件这个参数只在非默认安装路径时用。如果你的系统是 64 位但 GMP 装在/usr/local/lib64记得把 lib 路径改成/usr/local/lib64否则 configure 还是会拒绝。补充一个容易忽略的点Rocky/CentOS 上的包名是gmp-devel、mpfr-devel、libmpc-devel只装 gmp 运行时库同样会报这个错。所以看到这个报错先检查的是-devel包不是 GMP 本身。5.2 make 进行到一半进程被 killed日志最后没有红字现象make 跑十几分钟后终端突然没有任何报错只显示Killed或者进程直接消失/tmp/gcc-make.log最后一行停在某个.s或.o文件上。原因Linux 内核 OOM killer 把占用内存最高的编译进程杀了。GCC 编译 C 标准库时cc1plus 单进程峰值很容易超过 1.5 GB并行度一高就触发内存限制。解决先执行dmesg -T | tail -20看到Out of memory: Killed process基本上可以确认。然后降低并行度重新 makemake -j2 21 | tee /tmp/gcc-make.log-j2是最保守的并行设置适合 4 GB 内存的机器。如果连-j2都挂就加 swap命令在第 4 章已经写过。这里要说明的是make 重新执行时会自动跳过已经编译成功的对象文件所以你不用清空 build 目录从头再来这是 GNU make 的时间戳机制在起作用。还有一个不常见但很玄学的现象如果日志显示的是某条 GCC 内部断言错误而不是 OOM那可能是内存不稳定导致的假报错。这时候重跑同一条 make 指令有时会自动通过如果反复出现在同一个源文件上再去考虑是不是磁盘坏了或 swap 分区满了。5.3 Ubuntu 上 install 时报 Permission deniedapt 装 gcc 也失败过现象make install 执行到mkdir -p /usr/local/gcc-9.5.0/...时提示Permission denied然后安装中断。有人在之前 apt 安装 gcc 时也遇到过 apt 报错怀疑是源的问题。原因/usr/local默认只有 root 能写普通用户直接make install没有写权限。至于 apt 装 gcc 失败很可能和源码编译无关是源没更新好但如果你已经编译完成就不必再纠结 apt。解决最直接的方式是sudo make install。但我更推荐在 configure 阶段把--prefix指向用户目录比如--prefix$HOME/opt/gcc-9.5.0这样不依赖 sudo后面想卸载也方便。如果你的目标是给整机用那就sudo make install但安装完记得把 PATH 写入系统级/etc/profile.d/gcc-9.5.0.sh避免只在当前 shell 生效。这里有一个值得记住的经验源码目录本身不要用 sudo 去解压或编译。sudo 会把文件属主改成 root之后你再用普通用户维护这个目录就会遇到各种奇怪的权限问题。正确的做法是普通用户解压、普通用户编译只有 make install 用 sudo或者干脆 prefix 用用户目录。5.4 升级 gcc 后 gcc --version 还是旧版本现象安装完成、PATH 也 export 了但gcc --version仍然显示 4.8.5 或 7.5.0which gcc仍指向/usr/bin/gcc。原因/usr/bin/gcc是由 update-alternatives 管理的软链接它的优先级可能高于你的 PATH或者你的 shell 里 PATH 拼接顺序有问题。很多发行版把 gcc 的默认路径写在/etc/profile.d里而且是在你~/.bashrc之前被加载导致后添加的 PATH 没起作用。解决先看which gcc返回什么。如果是/usr/bin/gcc把 export 行放到~/.bashrc最末尾然后source ~/.bashrc。如果不想每次 source可以用 update-alternatives 把新 gcc 加进去sudo update-alternatives --install /usr/bin/gcc gcc /usr/local/gcc-9.5.0/bin/gcc 100 --slave /usr/bin/g g /usr/local/gcc-9.5.0/bin/g sudo update-alternatives --config gcc第一条命令注册了一个优先级为 100 的 gcc 新替代项同时通过--slave把 g 一起带过去保证切换 gcc 时 g 也切换。第二条命令让你手动选择当前默认的 gcc。这种方法的好处是全系统无条件生效但坏处是会侵入系统的/usr/bin目录我自己的机器上一般不用只在必须让系统默认 gcc 瞬间变成新版本的场景下才用。5.5 在 Kylin V10 上编译时缺依赖且链接 libstdc.so.6 找不到现象在 Kylin V10 上跑 configure 提示缺少基础编译工具或者编译完成后C 程序运行时报libstdc.so.6: cannot open shared object file。原因Kylin V10 的包管理基于 yum/dnf系统默认 gcc 往往还停留在 4.8.5 或更老版本自带的 libstdc 版本与 GCC 9 生成的 ABI 并不完全兼容同时有些软件源里没有libmpc-devel导致依赖检查不通过。如果你目标是编译 gcc 12问题会更明显因为 gcc 12 对 gmp/mpfr/mpc 的版本要求更高系统源里的版本通常不够用。解决先补齐基础环境再走第 3 章的 configure 流程sudo yum install -y gcc gcc-c make gmp-devel mpfr-devel libmpc-devel这一行把系统自带编译器、make 和三个依赖库的开发包全部装上。之后再重新 configure、make。动态库找不到时把 lib64 路径写进 ld 配置sudo sh -c echo /usr/local/gcc-9.5.0/lib64 /etc/ld.so.conf.d/gcc-9.5.0.conf sudo ldconfigecho 重定向是为了把新编译器的动态库路径加入系统加载器搜索列表ldconfig重新生成缓存。这样比每次 exportLD_LIBRARY_PATH更稳定但要注意如果以后系统升级会改变libstdc.so.6的 ABI这个目录要保持独立不要随便挪动。6. 让自编译的 GCC 长期可用多版本共存、验证方法与一个排错习惯6.1 多版本共存独立 prefix 加优先级可控的切换已编译的 gcc-9.5.0 如果装在独立 prefix 下完全可以和系统 gcc 并存。我的习惯是/usr/local/gcc-9.5.0只属于 9.5.0以后想换 12 就装到/usr/local/gcc-12需要切换时改 PATH 顺序即可。不要为了省事直接ln -s /usr/local/gcc-9.5.0/bin/gcc /usr/bin/gcc那样会绕过 update-alternatives 的管理系统升级时很容易出问题。多版本并存时哪个目录在 PATH 前面哪个版本的 gcc 就是默认值这是最简单的可控切换方式。6.2 验证方法与一个排错习惯验证新 gcc 不能只看版本号我建议编译一段真正用到 C17 特性的代码cat /tmp/t17.cpp EOF #include iostream #include optional int main() { std::optionalint o 42; std::cout o.value() \n; } EOF /usr/local/gcc-9.5.0/bin/g -stdc17 /tmp/t17.cpp -o /tmp/t17 /tmp/t17运行能输出42说明 GCC 9 的 C17 支持、标准库头文件路径和动态链接都没问题。这个用例比 hello world 更能暴露语言前端和 libstdc 的配合问题。再看一眼编译日志如果/tmp/gcc-make.log末尾出现make[1]: Leaving directory且 make 的退出码是 0这次源码编译就算闭环了。从那以后我每次遇到源码编译完不生效的问题都会先跑一遍which gcc readlink -f $(which gcc)确认当前指向再去调 PATH这个顺序能定位七成以上的环境坑。如果你之前也遇到 Ubuntu 安装 gcc 一直失败、升级后还是旧版本的怪问题不妨按这篇文章从头走一遍 gcc-9.5.0.tar.gz希望帮到你。本文还有配套的精品资源点击获取