先说一个不少人遇到过的情况手头一台 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_64glibc2.17libgcc4.8.5binutils2.27这几项直接决定了 RPM 包版本的范围。如果只是装 gcc 4.8.5 配套的包从 CentOS 7 官方仓库拿就行如果想装更高版本比如 gcc 9.x、10.x那就得一个一个核对依赖特别是 glibc 版本它往往是最大的限制条件。这里特别提醒一下CPU 架构马虎不得。现在国产化环境越来越多ARMaarch64、龙芯mips64el、申威sw_64都很常见下载 RPM 时一旦架构选错rpm 安装直接拒绝。常见架构与 RPM 后缀对照如下架构uname -m 输出RPM 包常见后缀主流服务器 / PCx86_64x86_64.rpmARM 64 位服务器aarch64aarch64.rpmARM 32 位armv7hlarmv7hl.rpm飞腾处理器aarch64aarch64.rpm龙芯处理器mips64elmips64el.rpm申威处理器sw_64sw_64.rpm我踩过最蠢的一次坑是给 ARM 机器下载了 x86_64 的 RPMrpm 安装时直接提示架构不匹配。后来换了 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 包之间的依赖关系。这个方式最省心强烈建议优先使用。方式二完全手动按依赖顺序安装。顺序大致是gmpmpfr依赖 gmplibmpc依赖 mpfrcpplibgompglibc-devel依赖 kernel-headersgcc命令无非是 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 切换版本先看看系统里有哪些 gccls /usr/bin/gcc* ls /usr/local/bin/gcc*然后把新版本注册到 alternativesalternatives --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 程序时如果报找不到库需要把对应路径加进 ldconfigecho /usr/local/lib64 /etc/ld.so.conf.d/gcc-local.conf ldconfig然后可以用以下命令确认系统找到了新的 libstdcldconfig -p | grep libstdc5. 链接库文件编译期链接与运行期链接是两回事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 过程中常见的问题整理成速查表方便直接对号入座现象可能原因解决思路rpm 安装报“wrong ELF class”下载了错误架构的 RPMuname -m 确认架构重新下载对应包安装时报依赖缺失依赖包未下载全用 yum localinstall 或按 gmp→mpfr→libmpc→cpp→glibc-devel→gcc 顺序装gcc -v 有输出但编译报 stdio.h 找不到缺少 glibc-devel下载并安装 glibc-develgcc 升级后版本没变PATH 优先级或 alternatives 未配置调整 PATH 或用 alternatives --config gcc运行程序报 libstdc.so.6 缺失运行期链接路径未更新ldd 定位缺失库加 ldconfig 路径并重建缓存运行程序报 GLIBCXX_3.4.x not foundlibstdc 版本过旧让新 gcc 的 libstdc.so.6 路径进入 ldconfig或使用静态链接国产系统装 CentOS RPM 报错软件源不兼容优先从系统官方软件源下载对应包我个人在实际操作中的体会是离线装 gcc80% 的时间其实耗在排查依赖上真正执行安装就是几分钟的事。所以最值得做的前置工作就是“一次拿全依赖包”。把 gcc、cpp、glibc-devel、libgomp、libmpc、mpfr、gmp 这些包全部放到同一个目录再执行 yum localinstall基本能避免九成以上的问题。最后再分享一个小技巧下载 RPM 之前先去目标机器的 /etc/yum.repos.d/ 看一眼。有些机器虽然不能连外网但可能配置了内网软件源只是 repo 文件被禁用了。如果内网源能用手动下载 RPM 根本不需要yum install 一行命令搞定。实在没有源再走手动下载这条路但理解了依赖关系后手动装也就是认真点的事完全不慌。
离线环境安装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_64glibc2.17libgcc4.8.5binutils2.27这几项直接决定了 RPM 包版本的范围。如果只是装 gcc 4.8.5 配套的包从 CentOS 7 官方仓库拿就行如果想装更高版本比如 gcc 9.x、10.x那就得一个一个核对依赖特别是 glibc 版本它往往是最大的限制条件。这里特别提醒一下CPU 架构马虎不得。现在国产化环境越来越多ARMaarch64、龙芯mips64el、申威sw_64都很常见下载 RPM 时一旦架构选错rpm 安装直接拒绝。常见架构与 RPM 后缀对照如下架构uname -m 输出RPM 包常见后缀主流服务器 / PCx86_64x86_64.rpmARM 64 位服务器aarch64aarch64.rpmARM 32 位armv7hlarmv7hl.rpm飞腾处理器aarch64aarch64.rpm龙芯处理器mips64elmips64el.rpm申威处理器sw_64sw_64.rpm我踩过最蠢的一次坑是给 ARM 机器下载了 x86_64 的 RPMrpm 安装时直接提示架构不匹配。后来换了 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 包之间的依赖关系。这个方式最省心强烈建议优先使用。方式二完全手动按依赖顺序安装。顺序大致是gmpmpfr依赖 gmplibmpc依赖 mpfrcpplibgompglibc-devel依赖 kernel-headersgcc命令无非是 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 切换版本先看看系统里有哪些 gccls /usr/bin/gcc* ls /usr/local/bin/gcc*然后把新版本注册到 alternativesalternatives --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 程序时如果报找不到库需要把对应路径加进 ldconfigecho /usr/local/lib64 /etc/ld.so.conf.d/gcc-local.conf ldconfig然后可以用以下命令确认系统找到了新的 libstdcldconfig -p | grep libstdc5. 链接库文件编译期链接与运行期链接是两回事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 过程中常见的问题整理成速查表方便直接对号入座现象可能原因解决思路rpm 安装报“wrong ELF class”下载了错误架构的 RPMuname -m 确认架构重新下载对应包安装时报依赖缺失依赖包未下载全用 yum localinstall 或按 gmp→mpfr→libmpc→cpp→glibc-devel→gcc 顺序装gcc -v 有输出但编译报 stdio.h 找不到缺少 glibc-devel下载并安装 glibc-develgcc 升级后版本没变PATH 优先级或 alternatives 未配置调整 PATH 或用 alternatives --config gcc运行程序报 libstdc.so.6 缺失运行期链接路径未更新ldd 定位缺失库加 ldconfig 路径并重建缓存运行程序报 GLIBCXX_3.4.x not foundlibstdc 版本过旧让新 gcc 的 libstdc.so.6 路径进入 ldconfig或使用静态链接国产系统装 CentOS RPM 报错软件源不兼容优先从系统官方软件源下载对应包我个人在实际操作中的体会是离线装 gcc80% 的时间其实耗在排查依赖上真正执行安装就是几分钟的事。所以最值得做的前置工作就是“一次拿全依赖包”。把 gcc、cpp、glibc-devel、libgomp、libmpc、mpfr、gmp 这些包全部放到同一个目录再执行 yum localinstall基本能避免九成以上的问题。最后再分享一个小技巧下载 RPM 之前先去目标机器的 /etc/yum.repos.d/ 看一眼。有些机器虽然不能连外网但可能配置了内网软件源只是 repo 文件被禁用了。如果内网源能用手动下载 RPM 根本不需要yum install 一行命令搞定。实在没有源再走手动下载这条路但理解了依赖关系后手动装也就是认真点的事完全不慌。