离线环境安装gcc全攻略：RPM依赖处理与版本切换实战

先说一个不少人遇到过的情况：手头一台 Linux 服务器，内网离线环境，没配本地 YUM 源，也没有挂载安装光盘，但项目编译任务催得紧，必须把 gcc 装好。这时候“直接下载 gcc RPM 包手动安装”就是最现实的解法。这篇内容我会把离线安装 gcc 的完整思路、依赖处理、版本切换和常见报错排查都梳理一遍，适合运维、嵌入式开发以及所有需要在离线 Linux 环境里装软件的朋友参考。

在实际动手之前，先把问题拆清楚：gcc 虽然是个编译器，但它不是单个 RPM 就能搞定的。它牵扯到 cpp、glibc-devel、libmpc、mpfr、libgomp 等一系列依赖包，这些包之间还有版本耦合关系。离线环境下最怕的就是“下载了一个 gcc 包，装的时候发现缺这个缺那个，又没法直接 yum 安装”。所以第一步不是急着下载，而是搞清楚目标系统的底细。

1. 装之前先弄清三件事：系统版本、CPU 架构、现有工具链

1.1 确认系统版本与架构

有些朋友拿到服务器就直接去下载 gcc，结果装的时候报错“wrong ELF class”或者“libc.so.6: version GLIBC_2.17 not found”，核心原因都是没搞清系统版本和架构。这里我习惯先跑这几条命令：

cat /etc/redhat-release uname -m rpm -qa | grep glibc rpm -qa | grep libgcc rpm -qa | grep binutils

以我最近处理的一台 CentOS 7.9 服务器为例，输出是：

• 系统版本：CentOS Linux release 7.9.2009
• 架构：x86_64
• glibc：2.17
• libgcc：4.8.5
• binutils：2.27

这几项直接决定了 RPM 包版本的范围。如果只是装 gcc 4.8.5 配套的包，从 CentOS 7 官方仓库拿就行；如果想装更高版本，比如 gcc 9.x、10.x，那就得一个一个核对依赖，特别是 glibc 版本，它往往是最大的限制条件。

这里特别提醒一下，CPU 架构马虎不得。现在国产化环境越来越多，ARM（aarch64）、龙芯（mips64el）、申威（sw_64）都很常见，下载 RPM 时一旦架构选错，rpm 安装直接拒绝。常见架构与 RPM 后缀对照如下：

我踩过最蠢的一次坑是给 ARM 机器下载了 x86_64 的 RPM，rpm 安装时直接提示架构不匹配。后来换了 aarch64 的包，一次就过了。所以先花一分钟查架构，能避免后面折腾半小时。

1.2 检查现有工具链，避免重复下载

还有一个容易忽略的点：系统里可能已经有部分依赖包了。用 rpm -qa 查一下 glibc、libgcc、binutils、gmp、mpfr 这些基础包，如果版本满足要求，就不需要重复下载。比如 CentOS 7 自带的 libgcc 4.8.5 和 glibc 2.17，在安装 gcc 4.8.5 系列时是可以直接复用的，那么下载时只需要补充 gcc、cpp、glibc-devel、libmpc 等缺失的包即可。

不过这里有个细节：如果系统被精简过，可能连 rpm 命令都没有。热搜词里就有一条“没找到rpm命令”，这种情况在 Debian/Ubuntu 系的系统上本来就正常，因为那是 dpkg 体系；但如果是精简版 CentOS 容器镜像，确实可能连 rpm 都没装。处理方式是 yum install rpm，把包管理工具先装回来。说实话，在非 RPM 体系里强行装 RPM 包我不太推荐，依赖容易搞乱，不如直接用系统原生的包管理方式。

2. RPM 包从哪来：下载渠道与在线下载技巧

2.1 官方仓库、镜像站与麒麟软件源

确定好系统版本和架构之后，下一步就是找 RPM 包。如果是 CentOS/RHEL 系，优先去官方 vault 仓库或 mirror 站点。CentOS 7 的包一般在 vault.centos.org 下，进入对应版本号目录，再进 os/x86_64/Packages/ 就能看到 gcc、cpp、glibc-devel、libmpc、mpfr、libgomp 这些包。需要注意，不同小版本（7.6、7.9）的依赖版本可能略有差别，尽量选择和目标系统一致的小版本。

如果是麒麟这类基于 RPM 体系的国产系统，我建议直接去对应的官方软件源或镜像站找。热搜词里的“银河麒麟 ssh 10.3 rpm升级包arm”，指的就是在 aarch64 架构的麒麟系统上装软件包。麒麟的软件源和 CentOS 并不完全一致，部分包名、依赖版本都有差异，特别是 glibc、libgcc 这种底层包，最好用麒麟仓库里的版本，不要直接拿 CentOS 的 RPM 硬塞。

2.2 用 yum downloadonly 一键拉全依赖

手动一个个找包确实费劲，而且容易漏。更稳妥的方式是在一台能上网、系统版本和目标机器相近的机器上，用 yum 的 downloadonly 插件把依赖一次下载齐全：

yum install --downloadonly --downloaddir=/root/gcc_rpms gcc

执行完以后，/root/gcc_rpms 目录下就会出现 gcc 以及它依赖的 cpp、glibc-devel、libmpc、mpfr、libgomp 等 RPM 包。然后再通过 U 盘、scp 或其他方式拷贝到内网机器上。

这个办法最大的好处是：依赖版本由 YUM 自动算好，不用自己逐个比对版本号。不过要注意，执行 downloadonly 的机器和目标机器的系统版本、架构要一致，否则下载下来的包可能不能用。比如在 CentOS 7.9 上拉取的包，装到 CentOS 7.6 上，偶尔会因为 glibc 或其他基础库版本略低而失败。

提示：如果目标机器上已经装了部分依赖，多下载的几个 RPM 也不会白费，安装时 rpm 会自动跳过已装且版本满足的包。下载时宁可多拿，不要少拿。

3. 离线安装的正确姿势：依赖顺序与安装命令

3.1 两种安装方式对比

拿到 RPM 包之后，最忌讳的就是直接一个命令装上：

rpm -ivh gcc-*.rpm

这样大概率会报错。因为 gcc 依赖的包不会自动帮你装，报错形如：

error: Failed dependencies: libmpc.so.3()(64bit) is needed by gcc-... cpp = 4.8.5-... is needed by gcc-...

处理方式有两种。

方式一：使用 yum localinstall，把当前目录作为本地软件源，让 YUM 自己解析依赖：

cd /root/gcc_rpms yum localinstall *.rpm

即使没有网络，yum localinstall 也能正常工作，因为它只解析当前目录下的 RPM 包之间的依赖关系。这个方式最省心，强烈建议优先使用。

方式二：完全手动按依赖顺序安装。顺序大致是：

1. gmp
2. mpfr（依赖 gmp）
3. libmpc（依赖 mpfr）
4. cpp
5. libgomp
6. glibc-devel（依赖 kernel-headers）
7. gcc

命令无非是 rpm -ivh 或 rpm -Uvh。顺序弄错了就会报缺失依赖，只能从头理一遍。我在生产环境里其实很少用纯手动方式，因为太容易漏，但有些精简环境下可能没有 yum 命令，那就只能按顺序来。

3.2 安装后的验证

安装完成后，先验证版本：

gcc -v gcc --version

如果 gcc -v 正常显示版本，但编译 Hello World 时报“stdio.h: No such file or directory”，那就是缺少 glibc-devel。gcc 编译器本身只负责把 C 代码变成机器码，标准头文件和 C 库得靠 glibc-devel 提供。所以下载时一定要把 glibc-devel 纳入清单，这是新手最容易漏的包。

4. gcc 升级后还是旧版本？大概率是 PATH 或 alternatives 的问题

4.1 PATH 优先级导致“升级无效”

热搜词里有一条“gcc升级后为啥还是旧版本”，我敢说十个人里面有八个是环境变量问题。比如 CentOS 7 自带 gcc 4.8.5，位于 /usr/bin/gcc；你自己在某处编译了 gcc 9，安装到了 /usr/local/bin。如果 PATH 是：

/usr/bin:/usr/local/bin

那么执行 gcc -v 的时候，系统先找到 /usr/bin/gcc，显示的还是 4.8.5。你以为升级失败了，其实新版本就在 /usr/local/bin 下，只是优先级不够。

解决办法有两种。第一种是改 PATH，把新版本目录放前面：

export PATH=/usr/local/bin:$PATH

这种改法只对当前会话有效，要想永久生效，写到 /etc/profile 或用户 ~/.bashrc 里。

第二种是用 alternatives 管理版本优先级，这种方式更规范，而且不会破坏系统原有 gcc 链接。

4.2 alternatives 切换版本

先看看系统里有哪些 gcc：

ls /usr/bin/gcc* ls /usr/local/bin/gcc*

然后把新版本注册到 alternatives：

alternatives --install /usr/bin/gcc gcc /usr/local/bin/gcc-9.3.0 100 alternatives --config gcc

--install 参数里的“100”是优先级，数字越大优先级越高。执行 alternatives --config gcc 后，可以手动选择使用哪个版本。切换完再执行 gcc -v，就能看到新版本号了。

这里有个衍生问题：如果你的新 gcc 是源码编译安装的，它自带的 libstdc++.so 可能不在系统默认库路径里。编译 C++ 程序时如果报找不到库，需要把对应路径加进 ldconfig：

echo "/usr/local/lib64" > /etc/ld.so.conf.d/gcc-local.conf ldconfig

然后可以用以下命令确认系统找到了新的 libstdc++：

ldconfig -p | grep libstdc++

5. 链接库文件：编译期链接与运行期链接是两回事

5.1 -l 与 ldconfig 的区别

热搜词里有一条“gcc链接库文件”，这个确实值得展开讲。很多刚入门 Linux 开发的人会把编译期链接和运行期链接搞混。

编译期链接靠的是 gcc 的 -l 参数，比如链接数学库：

gcc main.c -o main -lm

这里的“-lm”告诉 gcc 在编译阶段去链接 libm 库。编译期找不到头文件或库文件，会直接在编译命令报错。

运行期链接则由动态链接器 ld.so 负责。程序编译出来了，运行时会去查找它依赖的 .so 文件。查找路径由 /etc/ld.so.conf 和 ldconfig 缓存管理，也可以通过 LD_LIBRARY_PATH 临时指定。如果运行时报：

error while loading shared libraries: libstdc++.so.6: cannot open shared object file

说明运行期找不到这个库，跟编译期完全无关。排查时先用 ldd 看可执行文件缺哪些库：

ldd ./你的程序

输出的“not found”项就是问题所在。然后找到库文件的实际路径，写进 /etc/ld.so.conf.d/ 下的配置文件，执行 ldconfig，就能解决。

5.2 GLIBCXX 版本报错的处理

gcc 版本升级后，C++ 程序运行时常会遇到一类报错：

./app: /lib64/libstdc++.so.6: version GLIBCXX_3.4.26 not found

原因很简单：新版 gcc 编译出来的程序，默认链接的 libstdc++.so.6 版本比系统自带的老，运行时动态链接器在旧库里找不到所需的 GLIBCXX 符号。虽然 gcc 命令是新的，但运行程序时用的 libstdc++ 还是老的。

解决办法一般是把新版 gcc 的 libstdc++.so.6 所在目录加进 ldconfig，确保运行环境优先使用新版库。也可以用 strings 命令查看某个 libstdc++.so.6 到底支持哪些版本：

strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX

如果新版库路径确实已加入，但程序还是报错，就检查一下是否有多个 libstdc++.so.6 同时在查找路径里，并确认 ldconfig 缓存是否真的更新了。

6. 常见问题排查实录

最后把离线装 gcc 过程中常见的问题整理成速查表，方便直接对号入座：

我个人在实际操作中的体会是：离线装 gcc，80% 的时间其实耗在排查依赖上，真正执行安装就是几分钟的事。所以最值得做的前置工作就是“一次拿全依赖包”。把 gcc、cpp、glibc-devel、libgomp、libmpc、mpfr、gmp 这些包全部放到同一个目录再执行 yum localinstall，基本能避免九成以上的问题。

最后再分享一个小技巧：下载 RPM 之前，先去目标机器的 /etc/yum.repos.d/ 看一眼。有些机器虽然不能连外网，但可能配置了内网软件源，只是 repo 文件被禁用了。如果内网源能用，手动下载 RPM 根本不需要，yum install 一行命令搞定。实在没有源再走手动下载这条路，但理解了依赖关系后，手动装也就是认真点的事，完全不慌。