在 CentOS 7 上装 GCC很多人的第一反应就是yum install gcc装完跑gcc -v看一眼版本号就收工。但只要你真正在 CentOS 7 上折腾过 C/C 项目尤其是要编 C17/20 代码、碰 CUDA、给老系统补一个现代编译器或者被人问过“为什么升级完 GCC 后还是旧版本”就知道事情没那么简单。默认源里的 GCC 4.8.5 是 2013 年前后定型的编译器老归老却是整个系统 glibc 和内核模块的“原配”可一旦你追求新标准、新特性它又瞬间不够用。这篇文章就把我在 CentOS 7 上安装 GCC 的各种路径、踩坑记录和排查思路完整梳理一遍。从 yum 装系统自带版本到 SCL 软件集用上 devtoolset再到源码编译任意版本的高版本 GCC每条路线适合什么场景、会踩什么坑都会讲清楚。如果你正在为“GCC 版本不对、升级无效、GLIBCXX 找不到”这类问题头疼直接照下面的步骤走基本能稳住。1. 开工前先想清楚CentOS 7 上装 GCC 到底要解决什么问题1.1 为什么系统自带的 GCC 4.8.5 让人又爱又恨CentOS 7 从发布那天起系统仓库里带的就是 GCC 4.8.5。这个版本不是 CentOS 团队随便挑的而是跟随 RHEL 7 的企业级长期支持策略把编译器版本冻结在一个相对保守但足够稳定的节点上。整个系统的 C 库、内核工具链、系统级软件包在编译时都以这套编译器为基准所以用系统自带 GCC 编译出的程序最容易和系统环境兼容。但 4.8.5 的“稳定”是有代价的。它虽然能比较完整地支持 C11需要通过-stdc11开启但对 C14、C17、C20 基本是绝缘的。很多现代开源项目比如新版 CMake、TensorFlow 的 C 扩展、PaddlePaddle 的一些依赖甚至部分新版 Boost都已经默认用 C17 或 C20 语法。你拿着 4.8.5 去 configure往往会在语法检查阶段就挂掉。还有一个很现实的场景Python 或 Node.js 的某些原生模块在安装时会用当前环境的 GCC 去编译 C 扩展并动态链接新版libstdc.so.6。如果你之后把这套环境迁移到另一台只有老 libstdc 的机器上运行时就会报GLIBCXX_3.4.xx not found。这套连锁反应都是因为 GCC 版本和它的运行时库版本深度绑定。所以我的建议是不要在系统 GCC 一个树上吊死。先问清楚自己到底要它做什么。如果只是编译内核模块、系统服务、老的 C 项目用系统自带 4.8.5 最稳别折腾。但如果是要编译新标准代码、构建现代工具链、满足 CUDA 或其他厂商 SDK 的版本要求那就要换一条安装路线。1.2 三条路线选哪条yum、SCL 还是源码编译在 CentOS 7 上处理 GCC业内总结下来基本就是三条路。我直接做了个对比方便你对号入座安装方式能拿到的 GCC 版本安装速度对系统侵入性适合场景yum 直接安装4.8.5很快一条命令低直接装到系统目录系统级 C 开发、内核模块、老项目SCL / devtoolset最高到 GCC 11.x较快依赖都在仓库里中低装在 /opt/rh默认不影响系统 GCC需要新版本但又不想污染系统、不想自己编译源码编译任意版本11、12、13、14 都能编慢通常 1-3 小时可控可装在独立目录需要指定版本、离线环境、对版本有强诉求这三条路并不是互斥的。实际工作中我经常是系统 GCC 留着不动再用 SCL 或者源码装一个高版本编译具体项目时按需切换到对应环境。比如给 Keil 类嵌入式 IDE 配外部 GCC 工具链时很多人误以为 CentOS 上装个 GCC 就能用实际上那需要的是 ARM 交叉编译器跟这里的本机 x86_64 GCC 是两回事。本机 GCC 编译出的程序只能在当前 CPU 架构的 Linux 上跑这一点先分清能省下不少困惑。版本选择上有个经验值官方源和 SCL 能覆盖大部分场景如果你要尝鲜最新版本或需要某个特定版本号才建议走源码编译。源码编译也不是越新越好GCC 13/14 对新 C 标准支持好但编译耗时更长、依赖的 make/binutils 版本也可能要求更高选一个自己项目真正需要的版本即可。2. 一条命令打底把系统自带工具链先装对2.1 最小化安装最容易踩的坑只装了 gcc没装 gcc-c 和 makeCentOS 7 的很多服务器是最小化安装连编译工具链都没有。很多人执行yum install gcc装完后发现g命令不存在或者编译一个最简单的 C 文件直接报g: command not found。原因很简单在 CentOS 7 的软件包体系里gcc只提供 C 编译器gcc-c才是 C 编译器二者是独立的 RPM 包。还有配套的make很多源码包在 configure 阶段会检查 make 是否存在缺了它后面根本走不下去。我一般建议把这一组一次性装全sudo yum install -y gcc gcc-c make如果是最小化安装还可以顺手把kernel-devel装上因为后续如果要编译内核模块会用得到。不过单纯编译普通 C/C 程序上面三个包就够了。装完之后别急着往下走先验证一下三件套是否完整gcc --version g --version make --version正常你会看到gcc (GCC) 4.8.5以及对应的 g、make 版本。如果你看到的是 4.8.5说明环境已经可以干基础活了。2.2 基础环境验证时别忽视“能不能正常链接”这件事很多人验证 GCC 只看版本号但我建议多做一个动作实际编译一个带 C 标准库的小程序确认链接过程没有问题。因为有些系统环境里编译器装了可libstdc-devel这类开发库缺失编译单个 .c 文件没问题一编译 .cpp 就会在链接阶段报cannot find -lstdc。建一个测试文件跑一遍基础验证// hello.cpp #include iostream int main() { std::cout GCC toolchain OK std::endl; return 0; }g hello.cpp -o hello ./hello能正常输出GCC toolchain OK说明当前工具链是完整的不是“装了个半吊子”。这一步看起来很蠢但在排查问题的时候特别有用——它能帮你快速把“编译器本身坏了”和“依赖库缺失”区分开。我遇到过不少朋友一看到编译报错就怀疑 GCC 没装好其实只是缺了个-devel包。3. 一步到位的 SCL 方案不污染系统也能用上 GCC 113.1 SCL 和 devtoolset 是什么来头如果你不想碰源码编译又嫌弃 4.8.5 太老SCLSoftware Collections是 CentOS 7 上最优雅的折中方案。SCL 是 Red Hat 搞出来的一套“软件集合”机制可以让多个版本的软件包共存于同一台机器而且默认不覆盖系统自带的版本。GCC 对应的集合就叫 devtoolset里面除了 GCC还有配套的 GDB、binutils、make 等工具整体体验非常接近“一个现代化的开发环境”。SCL 的好处是“并行不悖”系统/usr/bin/gcc还是 4.8.5而scl enable devtoolset-11 bash之后当前终端里的gcc、g就变成了新版本。退出终端或重新登录系统又恢复原样。这种机制很适合不想影响系统级编译任务、又想在某个项目里用新编译器的场景。这里先列一下 devtoolset 和 GCC 版本的大致对应关系SCL 集合名称对应的 GCC 版本devtoolset-7GCC 7.xdevtoolset-8GCC 8.xdevtoolset-9GCC 9.xdevtoolset-10GCC 10.xdevtoolset-11GCC 11.x在 CentOS 7 上 devtoolset-11 基本就是 SCL 仓库里能拿到的较新版本了GCC 11 对 C17 支持很完整C20 也能用上大半覆盖绝大多数实际项目的需求。3.2 devtoolset 的安装、临时启用与永久生效安装 devtoolset 之前需要先安装 SCL 的仓库源。CentOS 7 上对应的包叫centos-release-sclsudo yum install -y centos-release-scl装好后就可以搜索并安装 devtoolset。以 devtoolset-11 为例sudo yum install -y devtoolset-11这里有一个可以优化的点如果只需要 GCCdevtoolset-11这个包会把完整的工具链带进来包括 gdb、binutils 等体积稍大但省心。如果你对磁盘空间敏感也可以只装devtoolset-11-gcc和devtoolset-11-gcc-c但后续调试时可能还是会把其他工具补齐。安装完成后临时在当前终端启用新版本scl enable devtoolset-11 bash gcc --version执行scl enable devtoolset-11 bash会重新拉起一个子 shell在这个 shell 里 PATH 和 LD_LIBRARY_PATH 都被改成了优先使用/opt/rh/devtoolset-11/root/usr/bin下的工具。此时运行gcc --version应该能看到 GCC 11.x 的输出。如果想让它永久生效最简单的方式是把 SCL 的 enable 脚本写入用户的 shell 配置echo source /opt/rh/devtoolset-11/enable ~/.bashrc source ~/.bashrc但我不太建议直接把这一步写到全局/etc/profile或所有用户的.bashrc里。因为它会把系统默认编译器悄悄替换掉一旦某些系统级软件自动编译时用了新 GCC连锁反应会比较难排查。比较稳妥的做法是给特定用户启用或者在项目构建脚本开头手动执行scl enable。3.3 用 SCL 时最容易忽略的三个暗坑SCL 用起来不算难但我在实际使用中遇到过几个容易让人懵的细节。第一个是 cron 或 systemd 服务里不生效。如果你写了一个定时任务去编译项目在交互终端里手动执行没问题但 cron 执行时环境变量是全新的不会加载 SCL 的环境。解决办法是在定时任务脚本里先写一行source /opt/rh/devtoolset-11/enable或者直接用绝对路径调用/opt/rh/devtoolset-11/root/usr/bin/gcc。第二个是 CMake 等构建工具在 SCL 环境下可能找错编译器。CMake 在第一次 configure 时会自动探测 C/C 编译器并把路径缓存到CMakeCache.txt。如果你之前已经跑过一次 configure当时用的是老 GCC现在切到 SCL 环境里再跑CMake 可能仍会用缓存里的老编译器。遇到这种情况删除构建目录下的CMakeCache.txt重新 configure 即可。第三个是 SCL 需要先安装centos-release-scl但这个包的依赖有时会因为网络源不稳定而中断。如果yum install centos-release-scl很慢或失败可以考虑切换为国内镜像源。SCL 仓库配置名一般是CentOS-SCLo-scl.repo检查一下/etc/yum.repos.d/下的配置是否指向了能访问的镜像站。4. 想要任意版本源码编译 GCC 的全过程拆解4.1 源码获取与版本选择的细节SCL 最高只到 GCC 11如果项目指定要 GCC 12、GCC 13或者你需要一个特定的修复版本号那就只能回归源码编译这条路。源码编译听起来吓人其实流程非常固定只要把依赖和 configure 参数搞清楚成功率非常高。先说源码从哪下。GNU 官方下载地址是 ftp.gnu.org但国内访问速度不太稳定。我一般直接用手边空闲的国内 GNU 镜像例如阿里云镜像或清华 TUNA 镜像。下载格式选.tar.xz体积比.tar.gz小不少wget https://mirrors.aliyun.com/gnu/gcc/gcc-13.2.0/gcc-13.2.0.tar.xz tar -xf gcc-13.2.0.tar.xz版本号怎么选如果你只是想要新我建议选 GCC 12 或 13 系列它们已经发布很久Patch 版本比较成熟。尝鲜 GCC 14/15 也不是不行但考虑到编译时间和可能遇到的新版本 bug生产环境我还是偏向用偶数稳定系列的较新补丁版。一个重要的构建规范不要在解压出来的源码目录里直接跑configure和makeGCC 官方推荐 out-of-tree 构建也就是单独建一个目录在目录里执行源码路径下的 configure。这样做的好处是编译产生的中间文件不会污染源码目录后续想清理或重新配置也方便mkdir gcc-build cd gcc-build4.2 编译依赖不是白给的gmp、mpfr、mpc 三件套GCC 源码编译最早遇到的拦路虎是三个数学库依赖GMP、MPFR、MPC。它们是 GCC 用来做高精度运算和优化判断的底层库没有它们configure 会在检查阶段直接报错内容大概是Building GCC requires GMP 4.2, MPFR 2.4.0, MPC 0.8.1。解决方式有三种我按推荐程度排序第一种最省事在源码目录里直接执行 GCC 自带的下载脚本cd gcc-13.2.0 ./contrib/download_prerequisites这个脚本会自动从 GNU 官方下载对应版本的 gmp、mpfr、mpc 源码包并解压到当前目录。等 configure 执行时GCC 会在源码目录里优先找到这些库并链接非常顺滑。第二种是系统有网络但脚本下载太慢时可以手动到 GNU 镜像站点下载这三个库的源码包放到 GCC 源码根目录并解压。需要注意版本配套GCC 11 以上对 MPFR 版本有最低要求解压后目录名里不要带版本号以外的多余后缀。第三种是直接yum install gmp-devel mpfr-devel libmpc-devel利用系统自带的开发库。CentOS 7 的仓库里也能装但版本比较旧某些新版 GCC 会报版本不足。所以除非你只是编 GCC 8/9 这种老版本否则我不推荐这个方案容易在 configure 检查阶段反复横跳。4.3 configure 参数逐个讲清楚configure 是源码编译里最关键的一步也是新手最看不懂的一步。我直接把常用命令摆出来然后说清每个参数的作用cd gcc-build ../gcc-13.2.0/configure \ --prefix/usr/local/gcc-13.2.0 \ --enable-languagesc,c,fortran \ --disable-multilib \ --disable-bootstrap--prefix指定安装目录。我强烈建议安装到带版本号的独立目录比如/usr/local/gcc-13.2.0而不是默认的/usr/local。因为默认/usr/local会和系统里大量自编译软件混在一起日后想卸载或切换版本非常麻烦。装到独立目录后整套 gcc、g、libstdc 都集中在/usr/local/gcc-13.2.0下面管理起来很清晰。--enable-languagesc,c,fortran指定要编译的语言前端。一般 C 和 C 是必须的fortrangfortran看你项目需要。这里不建议用--enable-languagesall因为有些语言前端如 Go、Ada在 CentOS 7 老环境下依赖较多编译时容易多出无关问题。--disable-multilib是一个很有意思的选项。multilib 是指让 GCC 同时支持 32 位和 64 位程序的编译。GCC 源码默认会尝试检测 32 位开发库glibc-devel.i686 等如果系统没装configure 阶段就会报错。对我们绝大多数只需要 64 位程序的场景直接--disable-multilib禁掉最省心。--disable-bootstrap需要多说两句。GCC 默认会做三阶段引导编译bootstrap也就是先用系统的旧编译器把新 GCC 编译一遍再用新 GCC 重新编译自己一遍最后再编第三遍验证结果。这个过程耗时长但能保证编译器自举的可靠性。很多教程为了省时间建议--disable-bootstrap我的建议是如果你时间充裕或者对编译出的编译器质量有较高要求可以保留 bootstrap如果只是自己在开发机上快速用禁掉也没问题我实际用下来没觉得稳定性有差别。4.4 make 编译与安装后的动态库配置configure 顺利通过之后进入漫长的 make 阶段。这里的核心问题是控制并行任务数和内存关系。简单说make -j$(nproc)能跑满所有 CPU 核心但 GCC 编译单个翻译单元非常吃内存。一台 2 核 2GB 内存的机器如果直接make -j2很可能会在编译过程中出现内存耗尽进程被杀最终留下一个“编译中断”的现场。我的经验公式是每个并行编译任务预留 1.5GB 到 2GB 内存。4GB 内存的机器用make -j2比较稳妥8GB 内存可以考虑make -j4。如果你不确定机器内存情况可以先看一眼free -h nproc然后按内存大小决定并行数。编译时间方面以 GCC 13 为例4 核机器全速编译大概需要 1.5 到 3 小时属于正常水平。中途如果因为内存不足被杀不需要从头再来直接降低并行数重新makeGCC 的构建系统会从断点继续。make 结束后执行安装sudo make install安装完成后最关键的一步来了动态库路径配置。因为新 GCC 安装到了/usr/local/gcc-13.2.0不在系统标准搜索路径里直接执行新 gcc 可能能跑但它编译出的程序运行时可能找不到新版的libstdc.so.6。先给动态库配置一个系统级搜索路径。在/etc/ld.so.conf.d/下新建一个文件echo /usr/local/gcc-13.2.0/lib64 | sudo tee /etc/ld.so.conf.d/gcc-13.2.0.conf sudo ldconfig然后设置环境变量把新 GCC 的 bin 目录放在 PATH 最前面export PATH/usr/local/gcc-13.2.0/bin:$PATH export LD_LIBRARY_PATH/usr/local/gcc-13.2.0/lib64:$LD_LIBRARY_PATH最后验证gcc --version g --version此时应该能看到gcc (GCC) 13.2.0。如果显示的仍是老版本就参照下一章的排查思路去查大概率是命令缓存或 PATH 顺序问题。5. 升级后为何 gcc -v 还是旧版本路径、缓存与动态库5.1 命令缓存和 PATH 顺序是怎么把你“骗”了的“升级完 GCC运行gcc -v还是旧版本”是我见过被问得最多的问题。这其实是 Linux 命令查找机制在作怪GCC 本身没装错只是 shell 还没找到它。先理解一个原理当你敲下gcc三个字母shell 会按 PATH 环境变量里从左到右的目录顺序去找可执行文件。echo $PATH能看出当前搜索顺序。如果你的新 GCC 装到了/usr/local/gcc-13.2.0/bin但 PATH 里/usr/bin排在它前面shell 就永远先找到/usr/bin/gcc也就是老版本。另外还有一个坑是 bash 的 hash 缓存。同一个终端里如果你之前敲过gccbash 会把它的完整路径缓存到内存中。之后即使你的 PATH 改了bash 可能还是直接命中缓存里的老路径。解决方法是执行hash -r清空命令路径缓存再重新执行gcc -v验证。这也是很多人改了 /etc/profile 后不重新登录就发现不生效的原因之一可以先不用开新终端hash -r往往就解决了。如果你不确定系统到底执行了哪个 gcc用which gcc看路径用type -a gcc查看所有候选路径这两个命令能帮你快速判断问题出在哪一层。5.2 GLIBCXX 报错的罪魁祸首libstdc.so.6和命令路径问题并列的高频坑是程序编译时一切正常运行时却报./a.out: /usr/lib64/libstdc.so.6: version GLIBCXX_3.4.29 not found。要理解这个报错得先明白 GCC 编译 C 程序时默认是动态链接libstdc.so.6的。GCC 版本越新生成的程序可能引用的GLIBCXX_符号版本就越新。如果你的程序是用 GCC 13 编译的而运行时系统加载的/usr/lib64/libstdc.so.6仍是 GCC 4.8.5 时代的老库那么老库里没有GLIBCXX_3.4.29这个符号程序自然跑不起来。这个问题的根源是“编译器新但运行时库旧”。所以只升级gcc命令还不够还要让动态链接器能找到新版libstdc.so.6。我在上一章提到的LD_LIBRARY_PATH和/etc/ld.so.conf.d/配置就是为了解决这件事。排查时可以用一个非常实用的命令strings /usr/lib64/libstdc.so.6 | grep GLIBCXX这个命令会把当前系统库支持的 GLIBCXX 版本都打出来。同理也可以对新版库执行strings /usr/local/gcc-13.2.0/lib64/libstdc.so.6 | grep GLIBCXX | tail -20两相对比就能确认新版库是否包含程序需要的符号。如果确认新库没问题那就把新库的路径加入运行环境的LD_LIBRARY_PATH。要是程序最终要部署到其他机器最简单的方案是把新版libstdc.so.6一起拷贝过去再通过LD_LIBRARY_PATH指定到本地目录也可以用 patchelf 之类的工具修改程序的 RPATH但复杂度更高一般环境够用就先用环境变量方案。5.3 多版本 GCC 和平共处的工程化切换一台 CentOS 7 机器上同时存在系统 GCC 4.8.5、SCL 或源码编译的新版 GCC是非常正常的状态。与其反复卸载重装不如把它们组织成可切换的“编译器环境”。我常用的做法是给源码安装的每个 GCC 版本写一个独立的 environment 脚本例如/etc/profile.d/gcc13.sh# 放在 /etc/profile.d/ 下会影响所有用户谨慎使用 # 如果只是自己用放在 ~/.bashrc 里更安全 export PATH/usr/local/gcc-13.2.0/bin:$PATH export LD_LIBRARY_PATH/usr/local/gcc-13.2.0/lib64:$LD_LIBRARY_PATH export CC/usr/local/gcc-13.2.0/bin/gcc export CXX/usr/local/gcc-13.2.0/bin/g需要哪个版本就在哪个终端 source 对应的脚本。这样每个项目都能在独立的 shell 环境中使用指定编译器互不干扰。SCL 场景则继续用scl enable devtoolset-11 bash或source /opt/rh/devtoolset-11/enable逻辑是一样的进入一个“新编译器环境”干完活退出系统其他部分保持原样。还有一个小技巧如果你不想切换整个环境只想用某个新 GCC 临时编译一次可以直接用全路径调用/usr/local/gcc-13.2.0/bin/g -stdc20 test.cpp -o test这样最直接避免环境变量干扰特别适合在脚本里临时调用。6. 离线环境与特殊工程场景的应对方案6.1 离线装 GCC 的 rpm 包路线很多企业内网服务器是物理隔离的不能直接访问外网但又有 yum 源或内网镜像。这类离线环境装 GCC最优先考虑的是 rpm 包路线。思路很简单找一台能联网、系统版本一致的 CentOS 7 机器用yumdownloader把需要的 rpm 包连同依赖全部下载到本地目录mkdir -p /tmp/gcc_rpms sudo yum install -y yum-utils sudo yumdownloader --resolve --destdir/tmp/gcc_rpms gcc gcc-c make--resolve参数会分析依赖并一并下载这是离线方案的核心。下载完成后把整个/tmp/gcc_rpms目录拷贝到离线机器上。在离线机器上安装时不要用rpm -ivh *.rpm一把梭因为 rpm 的依赖顺序不好控制有时会报依赖缺失让你一头雾水。更可靠的命令是sudo yum localinstall -y /tmp/gcc_rpms/*.rpmyum localinstall会分析本地 rpm 包之间的依赖关系并自动处理安装顺序只要下载的包足够全成功率很高。6.2 CentOS 7 安装 ISO 本地源兜底如果你连内网 yum 源都没有但有 CentOS 7 的 DVD ISO 镜像那也可以把它当本地源用。DVD ISO 里自带全套系统基础 rpm 包包括gcc、gcc-c、make。先把 ISO 文件挂载到系统sudo mkdir -p /mnt/iso sudo mount -o loop CentOS-7-x86_64-DVD-2009.iso /mnt/iso然后新增一个 local repo 文件指向这个挂载点# /etc/yum.repos.d/local.repo [local] nameLocal CentOS 7 ISO baseurlfile:///mnt/iso enabled1 gpgcheck0清缓存后安装sudo yum clean all sudo yum install -y gcc gcc-c make这种做法速度取决于硬盘读取速度但胜在稳定、离线可用。要注意它装的版本仍然是系统仓库里的 4.8.5所以只解决“有没有基础编译器”的问题。如果离线环境还需要更高版本 GCC那就得走源码包路线提前在有网环境把所有源码包准备好。6.3 CUDA 等工具链 “failed to verify gcc version” 怎么破很多人折腾完 GCC 之后发现本来不装新 GCC 还好好的 CUDA 安装程序突然报failed to verify gcc version. see log at /var/log/cuda-installer.log for details。这是因为 CUDA 安装器在开始安装前会检查当前环境中 GCC 的版本而每个 CUDA 版本都有自己支持的主机编译器版本范围。CentOS 7 上一些常用的 CUDA 版本支持的上限 GCC 往往在 8/9/10 上下。如果你把 PATH 里的gcc切到了 GCC 11 或更高CUDA 安装器一看版本超了就拒绝继续。这其实不算 GCC 安装失败而是“GCC 版本与 CUDA 期望不符”。建议的思路是找对版本组合。先查你所装 CUDA 官方文档中的编译器支持矩阵确认它最高支持哪个 GCC 大版本再决定是用 SCL 里的 devtoolset 还是源码编译对应版本。如果 CUDA 比较老可能还停留在 GCC 4.8.5 时代这时你就别轻易把系统默认 GCC 换掉而是在安装 CUDA 时指定 CC/CXX 指向受支持的编译器export CC/usr/bin/gcc export CXX/usr/bin/g把环境变量显式指到系统老 GCC执行 CUDA 安装脚本时就能避开版本校验失败。安装完成后编译 CUDA 扩展再用新 GCC 也不迟。这种“安装器用一个编译器后续开发用另一个编译器”的做法在实际项目中并不少见提前了解能少走很多弯路。7. 现场排障手册症状速查与处理建议7.1 高频报错与对应解法下面这张表是基于我在 CentOS 7 上折腾 GCC 时最常见的报错整理的。每一行都来自真实现场出现频率很高现象可能原因处理建议yum install gcc报 No package gcc availableyum 源配置有问题或 base 源不可达检查/etc/yum.repos.d/配置确认源能正常yum repolist装完 gcc但g命令不存在缺少 gcc-c 包yum install -y gcc-c编译 .cpp 文件报cannot find -lstdc缺少 libstdc 开发库安装libstdc-devel并确认 gcc-c 已装configure 报C compiler cannot create executables没有 C 编译器或 binutils 异常检查g --version、which as确认 toolchain 完整编译中进程被 kill提示内存不足make 并行任务数设置过高用make -j1或make -j2增加 swap 也可以gcc -v显示的还是旧版本PATH 顺序或 bash hash 缓存执行hash -r用which gcc确认实际路径运行新编译程序报 GLIBCXX_3.4.xx not found运行时加载的是旧
