简介：本资源是一套专为离线环境设计的GCC编译器完整离线安装方案，面向Linux系统运维人员、嵌入式开发工程师及无网络条件的教学/生产服务器管理员，解决在CentOS/RHEL 6类系统中无法联网安装GCC核心组件的痛点。压缩包共12个文件，含11个RPM二进制包（覆盖gcc-4.4.7、gcc-c++、cpp、glibc-devel、kernel-headers、mpfr、cloog-ppl等关键依赖）及1个可执行安装脚本，总大小24.09MB；RPM包提供编译器本体、C/C++标准库头文件与运行时支持，Shell脚本则封装了环境检测、依赖顺序解析与rpm --nodeps批量安装逻辑，显著降低手动处理依赖链的复杂度。目前已有556人学习下载，资源结构简洁明确，开箱即用，特别适合远程服务器部署、实验室封闭环境教学或灾备系统快速恢复编译能力等实战场景。
1. GCC 离线安装不是“下个 tar.gz 就完事”：它是一整套依赖拓扑的镜像重建工程
你手头有一台刚装好的 CentOS 7 服务器，没联网，但马上要编译一个 C++ 项目——make报错第一行就是gcc: command not found。你想起以前在能联网的机器上yum install gcc一行搞定，于是兴冲冲把gcc-4.8.5-44.el7.x86_64.rpm单独下载下来，rpm -ivh一跑，立刻卡死在error: Failed dependencies: glibc-devel is needed by gcc-4.8.5-44.el7.x86_64。再去找glibc-devel，又提示缺glibc-headers，接着是kernel-headers、mpfr、libmpc、cpp……最后你发现，GCC 不是一个软件，而是一张至少 37 个 RPM 包构成的强依赖网。离线安装的本质，不是搬运单个二进制，而是把整个构建生态的“最小闭包”完整抠出来、按拓扑序装进去。这份资源不是脚本合集，它是某一线工程师在三类典型离线场景（国产化信创环境、金融核心区物理隔离机房、嵌入式交叉编译宿主机）中反复验证过的RPM 包全量清单 + 拓扑解析脚本 + 安装校验机制。适合所有需要在无网络、无 yum 源、无互联网访问权限的 Linux 系统上，一次性、零报错、可复现地部署 GCC 编译工具链的运维、嵌入式开发和信创适配工程师。
2. 为什么必须用repoquery --requires而不是rpm -qpR？离线包采集的底层逻辑与实操路径
2.1 离线安装失败的根源：RPM 依赖图 ≠ 实际运行时依赖树
很多工程师第一次做离线 GCC 安装，会直接yumdownloader gcc，再对下载到的 RPM 执行rpm -qpR gcc-*.rpm，把输出里所有xxx = yyy行手动 grep 出来，挨个下载。这方法看似直觉，但会在第 3 个包就翻车。原因在于：rpm -qpR只读取 RPM 包头中声明的BuildRequires和Requires字段，它不处理yum 的元数据依赖解析逻辑—— 比如glibc-devel在不同版本中可能 Requireglibc = 2.17-324.el7，但实际系统里装的是glibc-2.17-325.el7，rpm -qpR不知道这个=是严格等于还是兼容版本，而yum会根据 repo 中的repodata做语义化比对。更关键的是，rpm -qpR完全忽略Provides字段（例如glibc-common提供glibc = 2.17），也跳过Obsoletes和Conflicts关系。结果就是：你凑齐了所有rpm -qpR列出的包，rpm -Uvh *.rpm仍报file /usr/include/stdio.h from install of glibc-headers conflicts with file from package glibc-devel—— 因为两个包都试图写同一个头文件路径，而rpm默认不允许覆盖，yum却能按事务顺序自动处理冲突。
提示：
rpm -qpR是静态包头快照，repoquery --requires是动态仓库拓扑查询。离线场景下，你没有仓库，但可以模拟仓库行为——这就是本资源脚本的核心设计前提。
2.2 正确采集路径：用yum-utils构建本地 repo 镜像，再用repoquery导出全依赖闭包
我们不直接操作单个 RPM，而是把目标系统（如 CentOS 7.9）的官方 base 和 updates 仓库，完整镜像到一台有网机器上，再从中精确提取 GCC 及其全部传递依赖。步骤如下：
# 在有网机器上执行（以 CentOS 7 为例） sudo yum install -y yum-utils createrepo # 创建本地镜像目录 mkdir -p /tmp/centos7-repo cd /tmp/centos7-repo # 同步 base 和 updates 仓库（仅同步 x86_64 架构，跳过 source 和 debuginfo） reposync -r base -p . --download-metadata --downloadcomps --arch=x86_64 --exclude='*.src.rpm' --exclude='*-debuginfo-*' reposync -r updates -p . --download-metadata --downloadcomps --arch=x86_64 --exclude='*.src.rpm' --exclude='*-debuginfo-*' # 生成本地 repo 元数据（关键！没有 repodata，repoquery 无法工作） createrepo -v -g comps.xml ./base/ createrepo -v -g comps.xml ./updates/同步完成后，目录结构为：
/tmp/centos7-repo/ ├── base/ │ ├── Packages/ # 所有 base 仓库 RPM │ └── repodata/ # 关键：包含 primary.xml.gz（含完整依赖关系） ├── updates/ │ ├── Packages/ │ └── repodata/此时，我们才能用repoquery精确获取 GCC 的最小依赖闭包：
# 设置本地 repo 源（临时） sudo tee /etc/yum.repos.d/local.repo << 'EOF' [local-base] name=Local Base Repo baseurl=file:///tmp/centos7-repo/base/ enabled=1 gpgcheck=0 [local-updates] name=Local Updates Repo baseurl=file:///tmp/centos7-repo/updates/ enabled=1 gpgcheck=0 EOF # 清除缓存并重建 sudo yum clean all sudo yum makecache # 查询 gcc 及其所有传递依赖（--resolve 自动解包依赖，--qf 输出格式化） repoquery --all --quiet --requires --resolve --qf "%{name}-%{version}-%{release}.%{arch}.rpm" gcc | sort -u > gcc-all-deps.list # 验证：该列表是否真能覆盖所有依赖？ # （检查是否有包名重复、是否含 kernel-* 等非必要包） wc -l gcc-all-deps.list # 正常应为 37~42 行（CentOS 7.9） grep -E "(kernel|firmware)" gcc-all-deps.list # 应为空，否则需过滤这段命令输出的gcc-all-deps.list是真正可交付的离线包清单。它比rpm -qpR多抓了 12 个包（主要是glibc-headers、libgcc、zlib-devel等隐式提供者），少抓了 5 个无关包（如kernel-tools）。这是离线成功的第一个分水岭：依赖清单必须由 repoquery 生成，而非人工拼凑。
2.3 为什么不能只同步gcc相关包？——--downloadcomps与comps.xml的不可替代性
你可能会想：既然只要 GCC，那reposync -r base --include=gcc*不就行了吗？不行。因为gcc的依赖中大量使用group依赖（如@development-tools），而comps.xml文件定义了这些组的成员包。--downloadcomps参数确保我们下载了完整的comps.xml，createrepo -g comps.xml则将其注入repodata。没有它，repoquery --requires --resolve就无法识别@development-tools这类高级依赖，导致漏包。这也是为什么本资源脚本强制要求--downloadcomps和createrepo -g—— 它不是可选项，是 GCC 离线安装的元数据基石。
3. 安装脚本不是简单 for 循环：它必须解决 RPM 安装序、冲突覆盖、缺失校验三大硬伤
3.1 为什么rpm -Uvh *.rpm必然失败？—— 依赖顺序与事务原子性缺失
当你把gcc-all-deps.list里的所有 RPM 放进一个目录，执行rpm -Uvh *.rpm，大概率会遇到两类错误：
error: Failed dependencies：因为rpm默认按字母序安装，而glibc-devel必须在gcc之前装，但gcc-*.rpm字母序靠前；error: unpacking of archive failed on file /usr/bin/gcc：因为cpp包和gcc包都提供/usr/bin/gcc，rpm不允许覆盖已存在文件。
标准rpm命令不具备依赖排序能力，也不支持事务回滚。解决方案是：用rpm的--nodeps --force强行覆盖？绝对不行——这会破坏系统一致性，后续yum update可能彻底崩溃。正确做法是：用rpm的--install模式 + 人工拓扑排序。
本资源提供的install_gcc_offline.sh脚本，核心逻辑是：
- 读取
gcc-all-deps.list，用rpm -qpR提取每个 RPM 的Requires； - 构建有向图：节点为包名，边为
A requires B； - 执行 Kahn 算法进行拓扑排序，得到安装序列；
- 按序列逐个
rpm -ivh（首次安装用-i，非-U，避免覆盖）； - 对于必须覆盖的包（如
glibc-headers和glibc-devel冲突/usr/include/stdio.h），用rpm -Uvh --replacefiles显式声明。
#!/bin/bash # install_gcc_offline.sh（节选核心排序逻辑） DEP_LIST="gcc-all-deps.list" RPM_DIR="./rpms" # 步骤1：构建依赖图（格式：package_name -> space_separated_deps） declare -A DEPENDENCIES while IFS= read -r rpm; do [[ -z "$rpm" ]] && continue pkg_name=$(rpm -qp --queryformat '%{name}' "$RPM_DIR/$rpm" 2>/dev/null) if [[ -n "$pkg_name" ]]; then # 获取 Requires，过滤掉 /bin/sh 等虚拟依赖 requires=$(rpm -qpR "$RPM_DIR/$rpm" 2>/dev/null | grep -vE "(^/|^/bin/sh|^rtld|^config\(|^rpmlib\()" | awk '{print $1}' | sort -u | tr '\n' ' ') DEPENDENCIES["$pkg_name"]="$requires" fi done < "$DEP_LIST" # 步骤2：Kahn 拓扑排序（简化版，生产环境用 python networkx 更稳） # 此处省略具体图算法实现，脚本中已封装为函数 topo_sort INSTALL_ORDER=$(topo_sort "${!DEPENDENCIES[@]}" DEPENDENCIES) # 步骤3：按序安装 for pkg in $INSTALL_ORDER; do rpm_file=$(grep "$pkg" "$DEP_LIST" | head -1) echo "Installing $rpm_file ..." # 关键：首次安装用 -i，对冲突文件显式 --replacefiles if rpm -qp --queryformat '%{name}' "$RPM_DIR/$rpm_file" 2>/dev/null | grep -qE "(glibc-headers|glibc-devel|kernel-headers)"; then sudo rpm -ivh --replacefiles "$RPM_DIR/$rpm_file" else sudo rpm -ivh "$RPM_DIR/$rpm_file" fi done逻辑说明：
--replacefiles仅用于头文件包之间的冲突（它们不改变运行时行为，只提供编译符号），绝不用在glibc或libstdc++等核心运行库上。参数说明：-i表示 install（非 upgrade），避免覆盖已有配置；--replacefiles告诉 rpm “我知道这个文件已存在，强制覆盖”，这是 GCC 离线安装中唯一被允许的覆盖操作。
3.2 安装后必须做的三件事：校验、环境变量、符号链接修复
安装完成不等于 GCC 可用。你还必须：
- 校验 RPM 数据库一致性：
rpm -Va | grep '^..5'检查文件 MD5 是否被意外修改； - 设置 PATH：
export PATH=/usr/local/bin:/usr/bin:/bin（某些离线环境默认 PATH 不含/usr/bin）； - 修复
cc符号链接：sudo ln -sf /usr/bin/gcc /usr/bin/cc（很多 Makefile 默认调用cc）。
本资源脚本在末尾自动执行：
# 校验所有 gcc 相关包 rpm -V gcc cpp glibc-devel glibc-headers 2>/dev/null | grep -v "^$" # 设置临时 PATH（写入 /etc/profile.d/gcc.sh 供全局生效） echo 'export PATH=/usr/bin:$PATH' | sudo tee /etc/profile.d/gcc.sh sudo chmod +x /etc/profile.d/gcc.sh # 创建 cc 链接 sudo ln -sf /usr/bin/gcc /usr/bin/cc sudo ln -sf /usr/bin/g++ /usr/bin/c++4. 避坑：GCC 离线安装的五个血泪现场与当场解法
4.1 现象：rpm -ivh报错error: Failed dependencies: libmpc.so.3()(64bit) is needed by gcc-4.8.5-44.el7.x86_64
原因：libmpc包名在 CentOS 7 中是libmpc-1.0.1-3.el7.x86_64.rpm，但rpm -qpR输出的依赖是libmpc.so.3()(64bit)，这是soname依赖，repoquery能自动映射到提供该 soname 的包，而人工下载时容易漏掉libmpc，只下了mpfr和gmp。
解决：严格使用repoquery --requires --resolve生成清单，不要手动补包。若已漏，执行repoquery --whatprovides "libmpc.so.3()(64bit)"查找对应 RPM。
4.2 现象：安装后gcc -v显示gcc version 4.8.5 20150623 (Red Hat 4.8.5-44)，但#include <vector>编译失败，报fatal error: vector: No such file or directory
原因：漏装libstdc++-devel包。libstdc++运行库已随gcc自动安装，但 C++ 标准模板库头文件在libstdc++-devel中，它不在gcc的直接 Requires 里，而在@development-tools组中。
解决：确保reposync时用了--downloadcomps，且repoquery命令未加--nogroups。检查gcc-all-deps.list中是否含libstdc++-devel-*.rpm。
4.3 现象：在国产化 ARM64 信创环境（如麒麟 V10）离线安装 GCC，rpm -ivh报package gcc-4.8.5-44.ky10.aarch64.rpm is intended for a different architecture
原因：gcc-all-deps.list是从 x86_64 仓库生成的，但目标机是 aarch64。repoquery默认返回当前机器架构的包，若在 x86_64 上查 aarch64 依赖，必须显式指定--archlist=aarch64。
解决：在有网的 aarch64 机器上执行同步和查询；或在 x86_64 上用repoquery --archlist=aarch64 --requires --resolve gcc，并确保reposync时加--arch=aarch64。
4.4 现象：安装后make仍报No rule to make target 'all'，检查发现make命令本身不存在
原因：gcc包不依赖make，make属于@development-tools组的独立组件。很多工程师以为装了 GCC 就有 make，其实没有。
解决：将make加入依赖清单：echo "make-*.rpm" >> gcc-all-deps.list，或在repoquery命令后追加--requires --resolve make。
4.5 现象：rpm -ivh过程中卡住不动，strace -p $(pidof rpm)显示阻塞在open("/proc/sys/kernel/random/uuid", O_RDONLY)
原因：离线环境缺少硬件随机数生成器（如/dev/hwrng），rpm在签名验证时尝试读取/proc/sys/kernel/random/uuid获取熵，但/dev/random耗尽，导致阻塞。
解决：安装前执行sudo yum install -y rng-tools && sudo systemctl start rngd（若有 rng 设备）；或临时关闭签名检查：rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 && rpm -ivh --nosignature *.rpm（仅限可信内网环境）。
5. 验证不是gcc -v就完事：用三层次编译测试覆盖 ABI、C++11、跨架构兼容性
5.1 第一层：ABI 兼容性验证 —— 确保生成的二进制能在目标系统原生运行
离线安装最怕 ABI 不一致。比如在 CentOS 7.6 镜像中生成的gcc-all-deps.list，若用于 CentOS 7.9，可能因glibc版本差异导致编译出的程序在 7.9 上Segmentation fault。验证方法是编译一个极简 C 程序，并用ldd检查其依赖的glibc版本是否匹配目标系统：
// test_abi.c #include <stdio.h> int main() { printf("Hello from offline GCC!\n"); return 0; }# 编译并检查 gcc test_abi.c -o test_abi ldd test_abi | grep libc # 正常输出应为：libc.so.6 => /lib64/libc.so.6 (0x00007f...) # 再检查该 libc 的 soname 版本 readelf -V test_abi | grep -A5 "Version definition" # 对比目标系统 /lib64/libc.so.6 的版本：ls -l /lib64/libc.so.6关键参数：
readelf -V显示程序所需的 GLIBC_2.17 等版本符号。若输出中出现GLIBC_2.28，但目标系统libc.so.6只提供到GLIBC_2.17，则 ABI 不兼容，需换用更低版本的 GCC RPM（如从 updates 仓库切回 base 仓库）。
5.2 第二层：C++11 标准支持验证 ——std::thread是最严苛的试金石
很多离线环境装完 GCC 后，#include <thread>编译通过，但运行时报undefined reference to 'pthread_create'。这是因为libstdc++编译时未链接libpthread。验证脚本：
// test_thread.cpp #include <iostream> #include <thread> void hello() { std::cout << "Hello from thread!\n"; } int main() { std::thread t(hello); t.join(); return 0; }# 编译命令必须显式加 -pthread（这是 GCC 离线安装后最容易遗漏的细节） g++ -std=c++11 -pthread test_thread.cpp -o test_thread # 运行前检查动态链接 ldd test_thread | grep pthread # 必须看到 libpthread.so.0 => /lib64/libpthread.so.0 ./test_thread # 应输出 "Hello from thread!"注意：
-pthread不是可选参数，它是 GCC 的特殊 flag，会同时触发预处理器定义（_GNU_SOURCE）和链接器参数（-lpthread）。离线环境中若漏掉，std::thread编译期不报错，链接期才失败。
5.3 第三层：跨架构交叉编译验证（可选但强烈推荐）
如果你的离线环境是嵌入式开发宿主机（如 x86_64 Ubuntu 宿主机，为 ARM Cortex-A9 目标机离线安装 GCC），必须验证交叉编译链是否完整。本资源附带check_cross_toolchain.sh：
# 检查是否存在 arm-linux-gnueabihf-gcc（以 ARM 为例） if command -v arm-linux-gnueabihf-gcc &> /dev/null; then echo "Cross compiler found" arm-linux-gnueabihf-gcc -dumpmachine # 应输出 arm-linux-gnueabihf # 编译一个裸机测试 echo 'int main(){return 0;}' | arm-linux-gnueabihf-gcc -x c - -o /dev/null 2>/dev/null && echo "Cross compile OK" else echo "Cross compiler missing — check if gcc-c++-arm-linux-gnueabihf package is in deps list" fi6. 我的离线安装 checklist 已迭代 7 个版本：从“能跑”到“可审计”的最后一道工序
每次给客户做信创适配，我都会在离线安装完成后，强制执行一套 5 分钟自检流程。它不保证 100% 万无一失，但能把 90% 的“当时觉得没问题、上线后崩”的玄学问题，在交付前掐灭。这套 checklist 不是文档，是刻在我肌肉记忆里的动作：
6.1 检查点一：RPM 数据库完整性（防 silent corruption）
# 1.1 检查所有 gcc 相关包是否完整安装 rpm -qa | grep -E "(gcc|glibc-devel|libstdc++-devel|cpp|kernel-headers)" | wc -l # CentOS 7.9 应返回 12（少于 12 说明漏包） # 1.2 校验关键包文件未被篡改 rpm -V gcc glibc-devel libstdc++-devel 2>/dev/null | grep -v "^$" || echo "All files verified" # 若输出为空，表示无异常；若输出如 "S.5....T. /usr/bin/gcc"，S=Size, 5=MD5, T=Mtime，说明文件被改过6.2 检查点二：编译环境纯净度（防 PATH 污染）
很多离线环境会残留旧版 GCC（如/opt/gcc-4.4.7），which gcc可能指向错误路径。我的做法是：
# 2.1 强制使用 /usr/bin 下的 gcc export PATH="/usr/bin:/bin:/usr/sbin:/sbin" which gcc # 必须输出 /usr/bin/gcc # 2.2 检查是否有多版本共存导致的头文件混用 gcc -E -x c /dev/null -I/usr/include | grep "glibc.*2\.17" # 确认头文件来自 glibc-devel-2.176.3 检查点三：ABI 兼容性快筛表（防版本漂移）
我维护一张速查表，放在gcc-offline-check/abi-compat.csv中，内容如下：
| Target OS | Required glibc | Provided by glibc-devel | Safe GCC RPM Version |
|---|---|---|---|
| CentOS 7.6 | 2.17-196 | 2.17-196.el7 | gcc-4.8.5-28.el7 |
| CentOS 7.9 | 2.17-325 | 2.17-325.el7 | gcc-4.8.5-44.el7 |
| Kylin V10 SP1 | 2.28-101 | 2.28-101.ky10 | gcc-8.3.1-5.ky10 |
每次拿到新系统，先cat /etc/redhat-release和rpm -q glibc，查表确认 GCC RPM 版本是否匹配。不匹配？立刻换源重做，绝不硬上。
6.4 检查点四：静默日志归档（防事后扯皮）
所有离线安装操作，我强制重定向 stdout/stderr 到时间戳日志：
# 安装时 sudo bash install_gcc_offline.sh 2>&1 | tee /var/log/gcc-offline-$(date +%Y%m%d-%H%M%S).log # 日志必须包含三要素：开始时间、结束时间、最终 `gcc -v` 输出 echo "=== INSTALL END $(date) ===" >> /var/log/gcc-offline-*.log gcc -v >> /var/log/gcc-offline-*.log 2>&1这份日志是交付物的一部分。客户问“你装的是哪个版本”，我不用回忆，直接tail -20 /var/log/gcc-offline-20240520*.log。
6.5 检查点五：一键回滚预案（后悔药必须存在）
离线环境最怕装错。我在脚本末尾固化一个回滚命令：
# 生成卸载命令（按安装逆序） tac gcc-all-deps.list | while read rpm; do pkg=$(rpm -qp --queryformat '%{name}' "./rpms/$rpm" 2>/dev/null) echo "rpm -e $pkg" done > uninstall_gcc_offline.sh chmod +x uninstall_gcc_offline.sh # 执行回滚（慎用！） # sudo ./uninstall_gcc_offline.sh它不保证 100% 干净（比如glibc不能卸），但能快速清除gcc、cpp、libstdc++-devel等非核心包，让系统回到初始状态。
从那以后我每次做离线安装，都强制走一遍这 5 个检查点——不是为了显得专业，是因为曾经在金融客户现场，因漏了libstdc++-devel，导致交易系统编译出的模块在生产环境凌晨 3 点 core dump，重启后恢复，但客户信任度掉了 30%。希望帮到你。
本文还有配套的精品资源，点击获取
