离线环境用RPM包安装GCC：本地源搭建与避坑指南

简介：这是一份面向 Linux 系统管理员的 GCC 离线安装资源包，旨在解决无外网或内网受限环境下无法使用 yum 或 apt 在线安装编译器的问题。压缩包采用 tar.gz 格式，整体约 24.11MB，共收录 24 个文件，其中 22 个为 RPM 包，另含 1 个 install_gcc.sh 安装脚本和 1 个 Readme.md 说明文档。RPM 包组不仅包含 gcc、gcc-c++ 主程序，还覆盖 libstdc++-devel、glibc-devel、内核头文件以及 mpfr、ppl、cloog-ppl 等关键依赖，同时收录 glibc-headers、kernel-headers 等系统级头文件，支持 C、C++、Fortran 等语言的编译开发，省去逐一查找依赖的麻烦。这些依赖包均针对 64 位 x86 架构，适用于常见服务器环境。配套脚本可自动完成依赖检测与安装流程，说明文档则提供清晰的使用指引，即便对 RPM 机制不熟悉的用户也能依据文档快速部署。资源已有 3991 人浏览学习，适合 CentOS/RHEL 6 等系统的开发者、运维人员以及需要离线搭建开发环境的实训场景。

1. 一个 tar 包背后：离线环境里 GCC 的交付方式

某天收到一份gcc_rpm.tar.gz，传到一台完全断网的服务器上。服务器上没有现成的编译工具链，业务代码等着编译上线。这个命名直白得不需要解释——里面装的是 GCC 编译器的 RPM 包集合。它解决的从来不是「下载安装」的问题，而是「没有外网时怎么把编译环境完整地搬进去」的问题。常见的做法是运维在一台能联网的机器上用下载工具把 GCC 及其依赖拉齐，打成 tar 包，再拷进内网分发。这篇文章按我实际处理的流程，从拆包、建源、安装到排错，把整条路径讲清楚。适合在内网、生产区、私有化环境里维护服务器的人，也适合刚接手这类交付物却不知道从哪下手的初级工程师。

2. 先读懂包里有什么：RPM 命名规则与 GCC 依赖链

2.1 先看清单再动手：tar -tzf与 RPM 文件名的三个信息位

拿到任何归档文件，我从不直接解压。第一步永远是列出清单，确认包的规模、版本和架构是否符合目标机器。这一步只要一条命令：

tar -tzf gcc_rpm.tar.gz | head -40

-t表示列出内容，-z表示解压前先解 gzip 压缩，-f指定文件。管道接head -40是因为一个完整的 GCC 依赖包集合通常有几十个文件，先看前 40 行就足够掌握大概面貌。如果这个归档在解压前就已经是几十个.rpm文件平铺，后面工作会顺利很多；如果看到的是嵌套目录，说明打包含了一层不必要的路径，需要留意。

清单里每一行的文件名都是信息的载体。以典型的gcc-8.5.0-18.el8.x86_64.rpm为例，三个信息位分别是版本号（8.5.0）、打包发布号（18.el8）、架构（x86_64）。el8表示针对 RHEL 8 系发行版构建，x86_64表示 64 位 Intel/AMD 架构。不同架构之间不能混装，这一点在内网环境里尤其容易翻车——后面避坑章节会专门展开。

如果你需要看完整清单而不是前 40 行，可以tar -tzf gcc_rpm.tar.gz > manifest.txt，之后反复查阅这个清单文件，不需要重新解压。清单还能用来做二次核对：到内网后rpm -qa看一下系统已装什么，再对比清单里有什么，能提前判断冲突。

2.2 摸清依赖链：GCC 不是孤立的一个包

很多新手误以为 GCC 就是gcc一个 RPM，装完就能编译。实际上现代 GCC 是一个复杂的依赖树。主包gcc只负责 C 编译器前端，真正的编译工作需要cpp（C 预处理器）、libgcc（底层运行时库），而 GCC 的数学运算依赖gmp、mpfr、mpc这三个基础库，从 GCC 8 开始又增加了isl作为新的依赖节点。这些库中的任何一个缺失，安装阶段就会直接报错。

离线环境里检查单个 RPM 包的依赖，用的不是安装那一刻才知道，而是提前用rpm查询：

rpm -qpR gcc-8.5.0-18.el8.x86_64.rpm

-q是查询，-p指定未安装的 RPM 文件，-R列出该包的全部依赖。输出里会出现形如libmpc.so.3()(64bit)、libisl.so.19()(64bit)这样以.so结尾的依赖项。看到这些就知道，gcc_rpm.tar.gz里必须配套存在mpc、isl、mpfr、gmp的包，缺一不可。

如果只是装 C 语言编译，gcc加上这几个库就够了。但实际业务很少只写纯 C，C++ 项目需要额外找gcc-c++，它提供g++命令；C++ 标准库的运行时部分在libstdc++，编译期头文件与链接文件在libstdc++-devel。这些包名在归档清单里应该一一对应出现。我的做法是在清单里先做一个grep -E "gcc|cpp|glibc|gmp|mpfr|mpc|isl"，把相关包全部列出来，人为建立一张依赖对照表，再决定安装顺序。

2.3 离线环境选 RPM 而不是源码编译的三个理由

有人会问：既然能拿到源码包，为什么非要用 RPM？离线环境下的三个实际理由决定了我几乎只选 RPM 路线。第一是可控性：RPM 的安装、升级、卸载都由包管理器记录和校验，哪天要回退版本，rpm -e一行搞定；源码编译默认装进/usr/local，卸载全靠手动，路径混乱很难收拾。第二是依赖闭环：RPM 包自带完整的依赖声明，配合本地源可以让yum自动解析依赖关系，避免手工编译时因为某个.so缺失而反复踩坑。第三是路径规范：RPM 安装的 GCC 直接落在系统标准路径/usr/bin/gcc、/usr/lib64，编译第三方源码时各种工具链脚本不需要额外配置PATH和环境变量。

当然源码编译有它的适用场景——比如需要自定义编译器参数、交叉编译特定平台。但那已经是另一类工作，不该出现在gcc_rpm.tar.gz这个标题的场景里。内网交付的核心诉求是「装得上、能卸载、路径别乱」，这三条全是 RPM 的强项。

3. 把归档变成可用仓库：本地源搭建与安装三条路

3.1 解包到工作目录：-C与权限保留

确认清单没有架构、版本问题时，开始解包。我把工作目录定在/opt下的一个独立目录，避免散落在家目录里被后续操作误删：

mkdir -p /opt/gcc_rpm mv gcc_rpm.tar.gz /opt/gcc_rpm/ tar -xzf gcc_rpm.tar.gz -C /opt/gcc_rpm

-x表示解包，-C指定解包目标目录。先mv再解，是为了让归档文件和释放的 RPM 包留在同一位置，后续配 repo 时路径统一。这里有一个容易忽略的点：如果归档打包时包含了目录层级（比如最外层有一个同名目录gcc_rpm/），解包后 RPM 会在/opt/gcc_rpm/gcc_rpm/下。可以用上一步清单来预判，再看一下find /opt/gcc_rpm -name "*.rpm" | wc -l，确认实际文件数量与清单一致。

解包后绝对不要在 RPM 文件上再执行一次解压操作。我接手过一个案例，某开发者把gcc-8.5.0-18.el8.x86_64.rpm当普通压缩包用tar -xvf解了一层，得到一个文件树，然后对着里面的usr/bin/gcc无从下手——RPM 不是 tar 归档，它的安装必须交给rpm或yum处理，人工解压得到的目录缺少数据库记录，既不能卸载也不能升级。

3.2 把目录变成 local yum 源：createrepo的使用

RPM 文件堆在一起还不能直接被yum识别，yum需要仓库元数据。离线环境最稳妥的仓库化方式是createrepo。先检查目标机器是否自带这个工具：

rpm -qa | grep createrepo

如果输出为空，说明系统没装，而内网又没有现成的源可用，这时候有两种替代：其一，把打包机器上的createrepo及其依赖 RPM 一并放进归档；其二，跳过仓库化，直接用yum localinstall。多数情况下我倾向于前者，因为仓库化是一次性投入，后续所有依赖解析都高效可靠。

假设createrepo可用，执行：

createrepo /opt/gcc_rpm

命令会在/opt/gcc_rpm下生成repodata/目录，里面是primary.xml.gz、filelists.xml.gz等元数据文件。之后写一个 repo 配置文件：

vim /etc/yum.repos.d/gcc-local.repo

文件内容如下：

[gcc-local] name=GCC Local Packages baseurl=file:///opt/gcc_rpm enabled=1 gpgcheck=0

baseurl指向 RPM 目录，file://协议表示本地路径，enabled=1让yum默认启用这个仓库，gpgcheck=0跳过签名校验。内网离线交付里，如果归档是内部打包的，签名校验意义不大，关了反而省去导入公钥的步骤；如果归档来自外部渠道，则建议保留gpgcheck=1并额外准备公钥文件。

3.3 安装主包：yum install与rpm -ivh的选择

仓库建好后，安装变得非常简单：

yum clean all yum makecache yum install -y gcc gcc-c++ cpp

yum clean all清掉旧的元数据缓存，yum makecache重新生成缓存，这两步在新增仓库后是必要的，否则yum可能找不到刚加的包。install后面跟的包名不需要写完整版本号，yum会根据仓库元数据自动选择最高版本并解析依赖树。

如果createrepo不可用，退而求其次用yum localinstall：

cd /opt/gcc_rpm yum localinstall -y ./*.rpm

yum localinstall会把当前目录下的 RPM 文件全部视为软件源，让yum的依赖解析器介入处理。它和rpm -ivh *.rpm的区别在于：rpm不会自动解决依赖，遇到缺包直接报错退出；yum localinstall会尝试在文件集合内寻找缺失的依赖。实际使用中，yum localinstall ./*.rpm会因为通配符展开把所有包作为安装候选，容易触发版本冲突，所以我的习惯是只写主包名，比如yum localinstall -y ./gcc*.rpm ./gcc-c++*.rpm，让yum按依赖自动拉取其余文件。

最后一种方法是rpm -ivh配合手动依赖排序，只在这两种方式都不可用时才采用。手动排序需要先rpm -qpR逐包分析依赖，按 gmp→mpfr→mpc→isl→cpp→gcc 的顺序逐个安装。这条路径效率低、容错差，但至少能让你在没有任何仓库工具的环境里完成工作。

4. 三个必调参数：让离线安装少走弯路

4.1keepcache与缓存保留策略

离线环境里最怕的是装到一半缺包，又没法重新下载。yum默认在安装成功后删除下载的 RPM 缓存，这对在线环境是省磁盘的好习惯，对离线环境却是隐患。在/etc/yum.conf里把缓存保留打开：

[main] keepcache=1

设置之后，yum install下载的所有 RPM 会保存在/var/cache/yum/对应仓库目录的packages/下。这个参数的实际价值体现在两种场景：一是安装完成后你又发现少了某个开发头文件，而这个文件其实随某个依赖包一起下载过，直接从缓存里翻出来就能装；二是你需要把这台机器上已下载的 RPM 再拷给另外几台服务器，缓存目录就是现成的打包来源。

另一个相关参数是installonlypkgs，它列出可以多版本并存的包。GCC 的升级场景里，如果担心新版本编译行为变化影响现有程序，可以把gcc加入该列表，实现新旧版本共存。默认值通常已包含kernel，需要追加时用逗号分隔：

installonlypkgs=kernel,gcc

不过这个参数在生产环境要谨慎使用，因为多版本并存意味着gcc命令指向哪个版本取决于alternatives的配置，没有配好时会出现命令行和实际版本不一致的困惑。

4.2gpgcheck与签名验证降级

gpgcheck是离线环境里最容易绊人的参数。本地仓库设gpgcheck=0是大多数内部交付时的默认选择，因为打包者未必把公钥一并交付，内网环境也没有查询公钥的外部通道。但这里要明确一个代价：当gpgcheck=1时，yum install会要求仓库元数据带签名，并且本机需要导入对应的公钥，否则安装报Public key for xxx.rpm is not installed。

如果你坚持签名校验，两个步骤缺一不可：第一，把公钥文件拷到内网某固定路径，比如/etc/pki/rpm-gpg/RPM-GPG-KEY；第二，在 repo 文件里显式声明gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY。导入操作：

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY

注意gpgcheck还有一个容易被忽略的层级：它同时存在于/etc/yum.conf的[main]段和 repo 文件里。默认全局是 1，repo 文件里单独设gpgcheck=0可以覆盖全局，反过来也是一样。排查签名问题时，两个文件都看一遍再下结论。

4.3 架构强制与releasever匹配

uname -m是最先应该跑的命令，它决定你后续所有选择。我在一台 aarch64（ARM 64）的服务器上见过有人硬装 x86_64 的 GCC 包，yum报错信息是package gcc-... x86_64 requires ...，看起来像是在提示缺依赖，实际上是架构根本不匹配。RPM 文件名里最后一个短横线后面的字段就是架构，常见的包括x86_64、aarch64、i686、noarch。noarch表示与架构无关，这类包两边都能装，但 GCC 主包永远是架构相关的。

yum install时可以用--setopt强制限定架构：

yum install -y gcc --setopt=arch=x86_64

这个参数的意义在于系统同时启用多架构仓库时，避免yum自动拉起 i686 版本的依赖包。另一个相关参数是releasever，它对应发行版版本号。如果你的gcc_rpm.tar.gz里的包是el8构建的，而目标系统是el9，yum可能拒绝安装或产生行为异常。检查方式：

cat /etc/redhat-release rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' gcc 2>/dev/null

目标系统的release字段和包里el后面的数字不一致时，不要硬装。宁可去找匹配的归档，也不要尝试--nodeps绕过，GCC 这种核心工具链的版本错配会造成编译出来的程序在运行时报各种诡异的段错误。

5. 避坑记录：离线装 GCC 的 5 个常见问题

5.1libmpc.so.3缺失导致事务检查失败

现象：执行yum install gcc时报错Error: Package: gcc-8.5.0-18.el8.x86_64 (gcc-local) Requires: libmpc.so.3()(64bit)。原因：打包者只把gcc主包放进了归档，忘了mpc、mpfr、gmp这些底层数学库，而yum在本地仓库里找不到对应的依赖包。解决：回到能联网的机器上，用下载工具把mpc、mpfr、gmp、isl全部拉下来，补进归档重新打包；如果内网其他服务器已有这些包，也可以从缓存目录/var/cache/yum里找到 RPM 直接rpm -ivh装上。我的习惯是在打包机器上执行一条yum install --downloadonly --downloaddir=/opt/gcc_rpm gcc gcc-c++，--downloadonly会把所有依赖一次性拉齐，避免手工逐个找。

5.2 装完gcc没有g++，编译 C++ 项目直接报错

现象：gcc装好后，执行g++ --version提示command not found。原因：g++命令由gcc-c++包提供，gcc主包只包含 C 编译器。解决：补装gcc-c++，同时确认libstdc++-devel也在仓库里，它是 C++ 头文件和链接库的提供者。这个坑的迷惑性在于g++这个名字让人误以为它和gcc在同一包里，实际 RPM 体系里它们是独立包。验收时除了gcc -v，一定要顺手跑一遍g++ -v。

5.3 新装 GCC 运行时报GLIBC_2.18 not found

现象：安装一切顺利，但用新 GCC 编译的程序换到另一台机器上运行时报/lib64/libc.so.6: version 'GLIBC_2.18' not found。原因：编译时用的 GCC 版本较新，生成的二进制依赖了更高版本的 glibc，而目标机器的系统库较老。解决：检查两边的 glibc 版本（ldd --version），确保编译环境的系统库不高于运行环境的系统库；或者在同一套 glibc 版本的机器上重新编译。这个坑和gcc_rpm.tar.gz本身关系不大，但它是离线交付 GCC 后最常见的一类连锁问题——GCC 装好了，编译的行为却受制于系统 glibc。

5.4 把 RPM 二次解压当文件树用

现象：有人解包gcc_rpm.tar.gz后，觉得里面的.rpm文件还要再解开才能拿到可执行文件，于是层层解压，最后得到一个usr/bin/gcc的文件，拷到系统里直接运行或链接。原因：对 RPM 的交付机制理解有偏差，RPM 是包管理器的安装格式，不是简单的文件归档。解决：RPM 文件必须用rpm -ivh或yum install交给包管理器处理。评估一个 RPM 的内容用rpm -qpl查询文件清单就可以了，不需要解压。擅自解压造成的直接后果是rpm -qa查不到这个软件，后续无法卸载和升级。

5.5 系统已有 gcc，本地源版本冲突

现象：目标系统自带了一个旧版 GCC（比如 4.8.5），而归档里是 8.5.0，yum install gcc时提示Package gcc-4.8.5-... already installed或者版本对比后不动作。原因：yum install默认安装的是满足依赖的最低可行版本，系统已有的旧包被认为是已满足条件。解决：显式指定升级版本：yum install -y gcc-8.5.0-18.el8.x86_64，或者yum update -y gcc。如果旧包干扰了本地源解析，可以先rpm -e gcc --nodeps删除旧包，再装新版，但删除前要确认没有存量程序依赖旧版本编译器产物，否则系统的某些自编译模块会跟着失效。

另一个场景是并发安装时yum报Protected multilib versions。原因很直接：归档里同时存在 32 位与 64 位包，yum的 multilib 保护机制不允许共存。解决：安装时显式指定架构--setopt=arch=x86_64，或者把归档里不需要的i686包移除。

6. 验证与扩展：从装好到能编译，还差这几步

装完 GCC 不是终点，我习惯在离开一台服务器前做一套完整的验证，这套验证也适用于你接手别人装好的环境时的快速体检。第一个命令是版本与配置确认：

gcc -v g++ -v ldd --version | head -1

gcc -v会输出完整的配置参数，包括--target（目标平台）和--enable-languages（支持的语言）。重点看两行：target 是否是当前机器架构；c、c++ 是否都在支持列表里。ldd --version输出 glibc 版本，用来建立编译—运行环境的关系基线。

第二个验证是实际编译一个 C 程序和 C++ 程序。我用的最小测试如下：

cat > hello.c << 'EOF' #include <stdio.h> int main() { printf("hello gcc\n"); return 0; } EOF gcc hello.c -o hello ./hello cat > hello.cpp << 'EOF' #include <iostream> int main() { std::cout << "hello g++\n"; return 0; } EOF g++ hello.cpp -o hello_cpp ./hello_cpp

如果两条命令都正常输出，说明编译器前端、头文件、标准库、动态链接器四个环节全部打通。接着再测试带数学库的链接：

gcc hello.c -o hello_math -lm

-lm链接libm数学库，这一步经常暴露glibc-devel缺失的问题——缺包时链接器报cannot find -lm，排错时先查glibc-devel是否安装。

验证全过之后，还有一个值得养成的习惯：把整台机器上由这个归档安装的 RPM 清单固化下来。

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | grep -E "^(gcc|gcc-c\+\+|cpp|mpc|mpfr|gmp|isl|libstdc)" > /opt/gcc_rpm/inventory.txt

这份清单文件用命令行重定向导出，内容包含了所有相关包的完整版本号。它有什么用？批量部署第二批服务器时，根据清单对比rpm -qa就能快速定位哪台漏装了哪个包；以后归档更新到新版本，也靠这份清单做差异对比。

再往后走，我会把「解包 → 建 repo → 安装 → 验证」这套动作固化成一个脚本，参数只留归档路径和目标安装目录。离线环境跑 GCC 的本质工作不是装一遍，而是把装的过程标准化、可重复。这个方向做扎实了，之后再来任何_rpm.tar.gz形式的交付物，处理时间能从一小时压缩到十分钟。最后一句我的个人教训：不要贪图省事跳过gpgcheck的确认步骤，也不要因为yum install一次成功就省略验证动作——离线环境里一旦出错，每次排查的时间成本都远比在线环境高。希望帮到你。

本文还有配套的精品资源，点击获取