gcc-9.5.0源码编译全解析：从configure到GLIBCXX动态库排坑

简介gcc-9.5.0.tar.gz 是 GNU 编译器集合 GCC 9.5.0 版本的完整源码包面向 C/C 开发者、系统构建者以及希望深入理解编译器实现原理的学习者。该版本对应 GCC 在 9.x 发行周期中的一个维护更新支持 C、C、Objective-C、Fortran、Ada 等语言适合用于学习编译原理、复现编译器构建流程或进行二次开发与定制优化。资源包整体约 122.2MB压缩包内文件列表仅显示 gcc-9.5.0 顶层目录文件总数记为 0实际内含编译器前后端源码、构建脚本与配置辅助文件主要文件类型以 C/C 源文件和相关脚本为主。当前已有 170 人学习下载。借助这份源码读者可以完整经历从配置、编译到安装的各个阶段深入查看多语言前端与优化后端的协作细节也能针对特定硬件或业务需求调整编译行为对教学研究、系统适配和开源贡献都具有较高的参考价值。1. gcc-9.5.0.tar.gz 到底解决什么问题为什么还要自己折腾一次源码编译拿到gcc-9.5.0.tar.gz这个压缩包很多人第一反应是“GCC 网上不是有安装包吗为什么还要下源码自己编”。真实情况是绝大多数发行版自带的 GCC 版本都很旧CentOS 7.9 默认还是 4.8.5Ubuntu 18.04 默认是 7.5项目里一个 C17 特性就能把老编译器干趴下。你想装新版本系统包管理器又不会给你推送只能手动下载 GCC 源码包来编译安装。gcc-9.5.0.tar.gz就是 GCC 9 系列的最终维护版本相比 9.1 到 9.4它累积修复了几十处后端 bug 和 C 标准库问题是很多做嵌入式、服务端开发的人选定的一条稳定基线。这篇文章要做的就是把“拿到这个 tar.gz 之后怎么办”这件事从头到尾讲清楚怎么下载、怎么校验、怎么 configure、怎么 make、怎么让新 gcc 真正生效以及那些你看网上教程十有八九会踩的坑。我自己在 x86_64 的 CentOS 7.9、Ubuntu 20.04 和 Kylin V10 上都用这套流程编过中间翻车次数不少这篇文章里写的每一条都是踩过之后才总结出来的希望你看完能少走一轮弯路。2. 拿到 gcc-9.5.0.tar.gz下载渠道、断点续传与文件校验2.1 优先走官方镜像列表别在第三方网盘拼运气GCC 的官方发布包都托管在 GNU 的 FTP 服务器上同时全球有一批官方镜像。你在浏览器里直接打开下载页速度往往不稳定尤其是 1GB 以上的源码包断一次就前功尽弃。我一般会先打开 GCC 官方的镜像列表页面挑一个地理位置近的镜像然后直接在服务器上用命令行下载。不要相信搜索引擎里那些“高速直链”那些第三方转存链接随时会失效而且你没法校验文件完整性。用 wget 下载时一定要加-c参数这样断网后重新执行会从断点续传不用重头再来。完整命令大致是这样wget -c https://mirrors.xxx.edu.cn/gnu/gcc/gcc-9.5.0/gcc-9.5.0.tar.gz说明一下-c是 continue 的意思让 wget 检查本地已下载部分的大小接着往下传。如果你所在网络对单线程下载限速很明显可以把 wget 换成 aria2 多线程拉取命令是aria2c -x 8 -s 8 -c https://mirrors.xxx.edu.cn/gnu/gcc/gcc-9.5.0/gcc-9.5.0.tar.gz-x 8表示每个服务器最多开 8 个连接-s 8表示拆成 8 段并行下载。对“下载 GCC 网速过慢怎么办”这类场景这是最直接的解法。需要注意前提是镜像服务器支持多线程断点续传GNU 官方镜像基本都支持。2.2 下载完之后先做 SHA256 校验别急着解压GCC 每个发布包都在官方页面给出了对应的校验值通常是 MD5 和 SHA256。这一步很多教程会跳过但你必须做。原因很实际源码包体积大、传输链路长中间任何一个字节出错后面 make 阶段就会出现莫名其妙的“internal compiler error”或者头文件找不到的错误到时候排查成本比现在高十倍。sha256sum gcc-9.5.0.tar.gz md5sum gcc-9.5.0.tar.gz把输出的哈希值和 GCC 官方页面上写的值对一遍两个都匹配再进入下一步。我习惯在下载完的同时把校验命令写进一个脚本里下次下载别的版本直接改文件名就能复用。解压命令没什么特殊的tar -xf gcc-9.5.0.tar.gz cd gcc-9.5.0tar -xf会自动根据文件扩展名识别压缩格式不需要手动加-z。解压后先别急着 configure下一步要检查编译依赖。2.3 解压后先检查源码树里的依赖脚本GCC 编译不像大部分 C 项目那样“解压就能编”它依赖 GMP、MPFR、MPC 三个数学库。如果你用的系统比较老这三个库的版本很可能不满足要求。常见做法是先用系统的包管理器装一份装不上再用 GCC 源码树自带的download_prerequisites脚本去拉./contrib/download_prerequisites这个脚本会自动下载 gmp、mpfr、mpc 三个源码包并解压到当前目录同时生成对应的软链接让 GCC 的 configure 脚本能找到它们。如果你所在的网络下载这几个包也很慢脚本支持设置镜像变量具体做法是先把gmp-*.tar.bz2、mpfr-*.tar.bz2、mpc-*.tar.gz手动下载好放进源码根目录再执行脚本它会检测到本地已有文件而跳过下载步骤。这一步做完才算真正具备开始 configure 的条件。3. configure 前的功课编译依赖、环境变量与最小配置3.1 不要直接在源码目录里 configureGCC 的官方文档和源码里的 INSTALL 文件都明确建议建立独立的 build 目录在 build 目录里执行 configure。这么做的原因有两个。第一GCC 的编译过程会产生大量中间文件如果在源码目录里编会把源码树搞得一团糟后续你如果想换一个配置重新编只能解压重来。第二有些老版本的 GCC 在源码目录内编译会出现奇怪的路径问题独立 build 目录能避开。mkdir -p build cd build ../gcc-9.5.0/configure --prefix/usr/local/gcc-9.5.0 \ --enable-languagesc,c \ --disable-multilib \ --enable-checkingrelease \ --with-system-zlib这里的参数我逐个解释一下。--prefix指定安装根目录我一般会带上版本号比如/usr/local/gcc-9.5.0这样将来如果想同时保留多个 GCC 版本直接切换目录就行。--enable-languagesc,c只编 C 和 C你把 Fortran、Ada、Go 都开开的话编译时间至少多出三分之一。--disable-multilib是 64 位系统上非常关键的一个参数如果不关闭GCC 会尝试编 32 位库而系统里往往缺少 32 位版本的 glibc 开发包configure 阶段直接报错。--enable-checkingrelease关闭编译器的内部调试检查只保留发行版级别的检查编出来的编译器性能更好。3.2 系统依赖没装齐会出现什么症状configure 阶段最常见的失败是找不到 GMP、MPFR、MPC。如果你是 CentOS 7.9直接执行yum install -y gmp-devel mpfr-devel libmpc-develUbuntu 和 Kylin V10 则用apt-get install -y libgmp-dev libmpfr-dev libmpc-dev注意 CentOS 的包名带-develUbuntu 的包名是lib*-dev这个区别经常让人踩坑。另外libmpc-dev在 Ubuntu 18.04 上可能默认没装要单独确认一下。还有一类依赖是文本工具和基础编译工具链。新装的最小化系统经常缺gcc、g、make、bison、flex。你可能会奇怪“我要装 GCC 为什么还要先有 GCC”因为第一版编译器需要一个已有的编译器或者引导编译器来编译自己。用系统自带的旧版 GCC 来编译新版 GCC这是最标准的引导方式。缺什么就装什么yum install -y gcc gcc-c make bison flex3.3 configure 失败时先看 config.log再上网搜如果 configure 跑到一半失败终端上会打印一段错误但真正的细节都在 build 目录下的config.log文件里。很多人在这一步盲目去搜索引擎复制别人的命令其实config.log已经把具体缺什么写得很清楚了。grep -n error config.log | tail -40这是我最常用的排查命令。config.log里会记录每一个编译测试的实际命令行和输出如果某个测试是因为头文件缺失失败的这里能看到具体是gmp.h找不到还是链接-lgmp失败。区别这两个问题很重要头文件找不到说明gmp-devel没装链接失败则说明可能装了 32 位版本而你系统是 64 位的。configure 成功之后终端最后几行会打印configure: creating ./config.status和configure: configuring in libstdc-v3之类的信息看到这些说明配置文件已经生成完毕。3.4 给 configure 传 CFLAGS 会改变编译器的“性格”默认情况下GCC 用自身默认的优化等级编译自己。如果你想编出一个对某种 CPU 架构做过专门优化的编译器可以在 configure 时传入CFLAGS和CXXFLAGS。比如我在 Kylin V10 的飞腾机器上编时会这样写../gcc-9.5.0/configure --prefix/usr/local/gcc-9.5.0 \ --enable-languagesc,c \ --disable-multilib \ CFLAGS-O2 -marcharmv8-a \ CXXFLAGS-O2 -marcharmv8-a但这里要提醒一句不要乱加-marchnative之类针对本机型号优化的选项因为编出来的编译器如果分发给别的机器用反而可能因为指令集不兼容没法运行。-marcharmv8-a这种偏通用的微架构级别就已经够用了。x86_64 机器上我一般不加-march默认的x86-64反而兼容性最好。4. make 与 make install并行编译、安装根目录与旧版本共存4.1 并行编译参数不要拍脑袋填先看一眼 CPU 核数configure 通过之后进入 make 阶段这一步最花时间。9.5.0 的完整源码包在四核机器上全量编译 c 和 c大概需要一到两小时在八核机器上能压缩到半小时以内。并行度由-j参数控制make -j$(nproc)$(nproc)会自动读取 CPU 核数并填进去不用你手动算。但这里有一个血泪教训如果机器内存小于 8GB-j开到满核会导致内存耗尽编译到一半进程被 OOM killer 杀掉。GCC 编译是典型的内存大户每个编译进程大约吃几百 MB 到 1GB 内存。四核 4GB 内存的云主机我一般只敢用-j2宁可慢一点也不要让进程被杀死之后从头再来。想让编译日志同时留到终端和文件里方便后来排查用 tee 重定向make -j$(nproc) 21 | tee make.log21把标准错误和标准输出合并tee make.log让它一边打印一边写入文件。等到 make 结束后如果想看哪里出了问题直接去 make.log 里搜error关键字比在终端翻屏方便得多。这里补充一个细节很多人只重定向了 stdout然后发现报错信息根本没进日志就是因为忘了处理 stderr。4.2 make 过程中最常见的两个中断场景场景一internal compiler error或者Segmentation fault但每次都发生在不同的文件上。这种情况大概率不是编译器源码有 bug而是内存不足或者磁盘空间不够。用df -h看一下当前目录所在分区至少留出 10GB 可用空间。场景二编译到 libstdc-v3 时提示找不到某个头文件翻看日志找不到明显的错误说明。这种情况通常是 configure 时依赖检测没真正通过你用了旧的 build 目录继续编。解决方式是把 build 目录整个删掉重新 configure 一遍而不是在残留的状态上打补丁。GCC 的构建系统对这个很敏感一次 configure 对应一套编译配置中途改了 configure 参数再直接 make结果不可预期。4.3 make install 之后验证二进制再考虑动 PATHmake 完全通过后执行安装make install安装过程很快通常一两分钟。它的本质就是把编译好的gcc、g、libstdc.so等文件复制到--prefix指下的目录里。由于我们指定了/usr/local/gcc-9.5.0所以安装后不会覆盖系统自带的 GCC这是“旧版本共存”的底气来源。安装完先直接运行完整路径验证一下/usr/local/gcc-9.5.0/bin/gcc --version看到gcc (GCC) 9.5.0的输出说明编译器本体没问题。这时候系统 shell 里默认调用的还是老版本 gcc要让新版生效需要修改 PATH 环境变量。export PATH/usr/local/gcc-9.5.0/bin:$PATH这里有个顺序陷阱必须把新版本的 bin 目录放在$PATH前面shell 才会优先找到新版。如果你写反了gcc --version打印的还是旧版本这就是“gcc 升级后为啥还是旧版本”最常见的原因之一。PATH 改了只对当前终端有效想全局生效就写进 profile 文件echo export PATH/usr/local/gcc-9.5.0/bin:$PATH /etc/profile.d/gcc-9.5.0.sh source /etc/profile.d/gcc-9.5.0.sh放在/etc/profile.d下面是为了让所有用户登录时都自动加载比直接改/etc/profile更干净卸载时删一个文件就恢复原样。4.4 动态库链接问题只改 PATH 不够GCC 编译出的程序运行时依赖新版libstdc.so而这个库通常装在/usr/local/gcc-9.5.0/lib64x86_64或/usr/local/gcc-9.5.0/libARM目录下。如果你的程序编译通过但一运行就报libstdc.so.6: version GLIBCXX_3.4.28 not found说明运行时加载的还是系统的旧库。解决方式有两种第一种是临时指定 LD_LIBRARY_PATHexport LD_LIBRARY_PATH/usr/local/gcc-9.5.0/lib64:$LD_LIBRARY_PATH第二种更彻底把新库路径写进系统动态链接缓存echo /usr/local/gcc-9.5.0/lib64 /etc/ld.so.conf.d/gcc-9.5.0.conf ldconfig我个人的习惯是选第二种。export LD_LIBRARY_PATH这种方式只在当前 shell 有效而且会影响所有程序容易串味。写到ld.so.conf.d之后所有程序都能正确加载新版运行库也不影响系统本身的库文件。顺便提一句如果你的车机上或者某个环境下不允许你动/etc/ld.so.conf.d那就在编译项目时用静态链接直接-static-libstdc -static-libgcc把 C 运行库编进可执行文件里绕开运行时加载问题。但这会让二进制体积大不少属于取舍问题。5. 安装和升级中的常见坑现象、原因与解决办法5.1 gcc 升级后一执行还是旧版本现象which gcc指到/usr/bin/gccgcc --version显示 4.8.5明明已经把新版装到/usr/local/gcc-9.5.0了。原因PATH 中没有把新版本 bin 目录排到前面或者改完 PATH 之后没有重新登录 shell。更高阶的情况是系统里存在一个/usr/local/bin/gcc的旧版软链接而这个目录恰好排在了/usr/local/gcc-9.5.0/bin前面。解决先执行which -a gcc查看所有 gcc 的候选路径按顺序列出。然后确认当前 PATH 内容echo $PATH手动调整顺序。针对旧软链接的干扰可以直接把它覆盖掉ln -sf /usr/local/gcc-9.5.0/bin/gcc /usr/local/bin/gcc但要意识到这会同时影响所有依赖/usr/local/bin/gcc的程序操作前确认有备份。5.2 configure 提示 GMP/MPFR/MPC 版本过低现象configure 执行到一半报错libmpc.so not found或者gmp.h is required。原因系统自带的这三个库版本太老。CentOS 7.9 自带的 gmp 是 4.3.1但 GCC 9.5.0 要求 gmp 4.3.2、mpfr 3.1.0、mpc 1.0.1 以上。版本不满足时即使包管理器装过gmp-develconfigure 也过不了。解决不要尝试在系统中强行升级这些基础库很容易把系统里其他依赖它们的程序弄坏。直接用源码目录下的./contrib/download_prerequisites脚本把三个库编进 GCC 源码树GCC 会优先使用源码树里的这三个库来编自己不会污染系统。这样做编译出来的 GCC 自身运行不依赖系统这三个库的版本安全得多。5.3 make 时进程被 OOM killer 杀死现象编译进行到一半终端突然什么都不输出过一会儿出现Killed字样dmesg | grep -i oom能看到内核杀进程记录。原因-j并发数太高机器内存不够。GCC 内部有好几个编译阶段其中有些阶段对内存特别敏感比如当前编译单元比较大的 C 模板实例化单进程就能吃掉 1.5GB 内存。解决根据机器内存调整并行度。4GB 内存用-j28GB 内存可以-j416GB 内存再放开到-j$(nproc)。还有一个备用方案不用改并行度而是降低优化等级编译 GCC 自身configure 时加CFLAGS-O1能显著降低峰值内存代价是编出来的 gcc 性能稍微差一点。对大多数使用场景O1 和 O2 的差别体感不大。5.4 程序编译通过但运行时报告 GLIBCXX 版本不存在现象用新版 g 编出来的可执行文件在另一台机器或当前机器运行时报/usr/lib64/libstdc.so.6: version GLIBCXX_3.4.28 not found。原因编译时链接的是新版libstdc.so但运行时动态链接器加载到的仍是系统自带的旧版库。这个现象很有迷惑性因为你用ldd看可执行文件显示 libstdc.so.6 路径可能是/usr/lib64/libstdc.so.6而新版库明明编译时用的是另一个路径。解决在处理这个坑之前我先强调一下怎么验证问题根源。执行strings /usr/local/gcc-9.5.0/lib64/libstdc.so.6 | grep GLIBCXX | tail确认新版本库确实包含高版本的 GLIBCXX 符号。然后按 4.4 节的方法把新库目录写进/etc/ld.so.conf.d并执行ldconfig。如果程序是你自己开发并且可以修改编译参数也可以直接-Wl,-rpath,/usr/local/gcc-9.5.0/lib64把运行库搜索路径硬编码进可执行文件。注意-Wl,-rpath只影响这个程序不影响其他程序排查阶段用这个方式更干净。5.5 编译过程中日志文件占满磁盘现象make 跑了很久之后报No space left on device或者disk quota exceeded。原因GCC 的中间文件非常多编 c 和 c 两门语言时包括各种 staging 目录、临时汇编文件和调试信息文件总占用很容易超过 8GB。如果/tmp和 build 目录在同一个分区这个分区不够用时会先体现在/tmp写临时文件失败上。解决编译前先df -h确认 build 目录所在分区有 10GB 以上空间。另外把TMPDIR和环境变量指到一个大分区的目录下比如export TMPDIR/var/tmp然后再启动 make。我碰到过一次/tmp只有 1.8GB 导致整轮编译失败的场景换到/var/tmp之后问题消失这类问题单纯从 GCC 的报错信息很难定位容易让人怀疑是源码问题。5.6 Kylin V10 上编译 GCC 12 成功但 9.5.0 失败的差异这个坑和热词里“kylin v10编译gcc 12”有关我单独拿出来说一下。有人会认为“能编 GCC 12 就一定能编 GCC 9.5.0”其实不一定。Kylin V10 基于的 glibc 版本较新GCC 9.5.0 的构建脚本对某些新头文件里的定义处理不兼容最典型的现象是 configure 阶段libstdc-v3的检查过不去或者编译时提示某个系统头文件里的语法不兼容。遇到这种版本错位不要死磕两个办法任选第一强制指定--enable-checks相关参数关掉部分严格检查第二如果系统里已经能用包管理器装 GCC 9 系列直接用系统包不一定非要源码装。你在 Kylin 上跑的项目关心的是编译器版本号够不够高而不是“一定要从这个 tar.gz 编出来”。我自己最后用的是先系统装一份 gcc-9 再切成源码编译的 gcc-12两者共存按项目分 PATH 使用。6. 用这套 gcc-9.5.0 做一次“新代码 旧项目”的验证装完 GCC 9.5.0别急着把整个系统切过去先做一次快速验证确认编译和运行这两条链路都通了再在真实项目上使用。我每次装完新编译器都会跑三个层次的验证第一层确认编译器版本第二层确认运行库版本第三层拿一个真实的老项目试编译。先跑最小程序验证编译器本身能工作cat test.cpp EOF #include iostream #include string int main() { std::string s gcc-9.5.0; std::cout s ok, c __cplusplus std::endl; return 0; } EOF /usr/local/gcc-9.5.0/bin/g -stdc17 test.cpp -o test_950 ./test_950如果输出正常说明编译器、标准库、动态链接全都通了。__cplusplus在 C17 下打印201703L如果你的项目代码里有用到 C17 特性这一步就能看出编译器是否真的支持。再检查动态库符号strings /usr/local/gcc-9.5.0/lib64/libstdc.so.6 | grep GLIBCXX | sort -V | tail -5正常会看到GLIBCXX_3.4.28甚至更高版本这就是前面提到的 9.5.0 对应的 C 运行库版本号。如果这里列出的最高版本只有 3.4.19说明你链接的库不对应该回去重新确认编译时是不是真的用了新版的libstdc。第三个验证最贴近真实使用找一个以前用老 GCC 编译的项目最好是你自己维护的重新编译一次然后运行它的测试集。这里有一个非常典型的差异GCC 9 默认启用了-fno-common和 GCC 4.x/5.x 时代的行为不同。老项目里如果存在多个编译单元重复定义某个全局变量的情况老编译器只给警告GCC 9 直接报错链接失败。这不是 GCC 9.5.0 的 bug而是新规范使然遇到就改代码把全局变量改成extern加唯一定义处或者加-fcommon临时压住。链接失败时 GCC 会明确提示multiple definition of ...你可以先加-fcommon让项目先跑起来再排期改代码。如果你手头有老旧 C 代码还可以试一试-Werrorimplicit-function-declaration这类新版本更敏感的警告级别GCC 9 里隐式函数声明默认只给警告但在 10 以上的版本里会直接变成错误。9.5.0 是承上启下的一个版本既能让你把代码迁移到接近 C17/C17 的语法标准又不会像 GCC 10/11 那样把很多老代码里的警告直接升级成错误所以很多做历史项目维护的团队愿意固守这个版本。用它把项目里的警告清一遍等将来要上 GCC 12 时迁移成本会小很多。最后收个尾说句实在话。从gcc-9.5.0.tar.gz这个压缩包到自己能放心用的 gcc 命令中间真正花时间的不是 CPU 编译的那几十分钟而是和 PATH、动态库、版本残留这些环境问题纠缠的时间。我现在的习惯是一台机器上永远只保留一个源码安装的 GCC目录带版本号用/etc/profile.d下的软链做版本切换凡是运行时报GLIBCXX_* not found第一步永远是去翻ldd和/etc/ld.so.conf.d里的配置而不是重编一次。这样的工作流一旦固定下来装任何新版本都只是换个文件名重走一遍流程希望这篇文章里写下的这些步骤和坑能帮你把这条路走得更顺一点。本文还有配套的精品资源点击获取