简介本资源是一套专为离线环境设计的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.09MBRPM包提供编译器本体、C/C标准库头文件与运行时支持Shell脚本则封装了环境检测、依赖顺序解析与rpm --nodeps批量安装逻辑显著降低手动处理依赖链的复杂度。目前已有556人学习下载资源结构简洁明确开箱即用特别适合远程服务器部署、实验室封闭环境教学或灾备系统快速恢复编译能力等实战场景。1. GCC 离线安装不是“下个压缩包解压就完事”它是一整套依赖拓扑的闭环重建专治内网服务器、无网编译环境、国产化信创节点的“编译失语症”你有没有遇到过一台刚装好的国产操作系统服务器连不上外网gcc --version报错“command not found”yum install gcc却提示“Failed to synchronize cache for repo”或者apt-get update直接卡死在 DNS 解析这不是配置问题是环境缺失——GCC 不是单个二进制而是一组强耦合的工具链预处理器cpp、编译器gcc/g、汇编器as、链接器ld、运行时库libgcc、libstdc、头文件glibc-headers、构建辅助make、autoconf 等隐式依赖……少一个./configure就会跪在checking for C compiler... no。这份资源不是“GCC 安装包合集”而是按真实发行版CentOS/RHEL/Ubuntu/Debian和架构x86_64/aarch64精准切分的离线依赖树快照 自动解析一键部署脚本。它面向三类人信创项目交付工程师要30分钟内让飞腾麒麟服务器跑通CMake、嵌入式固件编译岗ARM64交叉编译链离线预置、高校实验室管理员统一为200台无网教学机批量初始化开发环境。它解决的不是“能不能装”而是“装完能不能立刻编译OpenSSL、能不能跑通autotools项目、会不会因libstdc.so.6版本错位导致segment fault”——这才是离线场景下真正的血泪痛点。2. 离线包不是随便打包必须按发行版源仓库镜像结构重建否则依赖解析必翻车2.1 为什么不能直接tar -czf gcc-all.tar.gz /usr/bin/gcc*——GCC 的依赖藏在“看不见”的地方很多工程师第一次做离线部署习惯性把/usr/bin/gcc、/usr/lib64/libgcc*手动拷出来打包。结果在目标机上chmod x后一执行报错error while loading shared libraries: libmpfr.so.4: cannot open shared object file: No such file or directory这根本不是 GCC 本体的问题而是它动态链接的数学库MPFR、多精度库GMP、并行计算库ISL、C标准库头文件glibc-devel全都没带。更隐蔽的是gcc命令本身不依赖libmpfr.so.4但gcc -E预处理或gcc -O2优化触发的内部 pass 会调用它。这种“运行时才暴露的依赖”ldd /usr/bin/gcc都查不到——因为它是 dlopen 动态加载的。所以离线包必须从源仓库元数据repodata出发用repoquery --requires --resolve gccRHEL系或apt-rdepends --build-depends --followDepends gccDebian系反向抓取完整依赖图谱再按依赖层级排序下载。我们提供的脚本正是这么干的它不信任“经验判断”只信任yumdownloader --resolve和apt download的原始输出。2.2 CentOS/RHEL 离线包结构以baseosappstream双仓库为基准的最小可行集以 CentOS Stream 8 / RHEL 8 为例GCC 11 工具链分布在两个仓库baseos: 提供glibc,glibc-devel,zlib,bzip2-libs,xz-libs等底层运行时appstream: 提供gcc,gcc-c,gcc-gfortran,libmpc,mpfr,gmp,isl,binutils,make,autoconf,automake,libtool等编译工具。提示不要忽略glibc-devel它提供/usr/include/stdio.h等头文件没有它#include stdio.h直接报错No such file or directory且错误发生在预处理阶段比链接错误更早、更难定位。我们提供的离线包目录结构严格复刻reposync同步结果gcc-offline-rhel8-x86_64/ ├── baseos/ │ ├── Packages/ │ │ ├── glibc-2.28-211.el8.x86_64.rpm │ │ ├── glibc-devel-2.28-211.el8.x86_64.rpm │ │ └── ... │ └── repodata/ # 必须包含否则 yum localinstall 无法解析依赖 ├── appstream/ │ ├── Packages/ │ │ ├── gcc-11.4.1-2.1.el8.x86_64.rpm │ │ ├── gcc-c-11.4.1-2.1.el8.x86_64.rpm │ │ ├── mpfr-3.1.6-1.el8.x86_64.rpm │ │ └── ... │ └── repodata/ └── install.sh # 自动挂载本地 repo 并安装2.3 Ubuntu/Debian 离线包结构.deb包 Packages.gz元数据双保险Ubuntu 20.04/22.04 的 GCC 依赖更碎单个gcc-11包拆成gcc-11-base,gcc-11,libgcc-11-dev,libstdc-11-dev,cpp-11,g-11等且apt依赖解析强依赖Packages.gz中的Depends:字段。若只下载.deb文件dpkg -i *.deb会因顺序错误失败比如先装gcc-11再装libgcc-11-dev后者可能覆盖前者需要的符号链接。我们的解决方案是用apt download下载所有.deb用apt-ftparchive packages . Packages生成本地Packages文件用gzip -k Packages生成Packages.gz构建apt本地源结构gcc-offline-ubuntu2204-amd64/ ├── pool/ │ ├── main/ │ │ ├── g/gcc-11/ │ │ │ ├── gcc-11_11.4.0-1ubuntu1~22.04.1_amd64.deb │ │ │ └── libgcc-11-dev_11.4.0-1ubuntu1~22.04.1_amd64.deb │ │ └── m/mpfr4/ │ │ └── libmpfr6_4.1.0-3_amd64.deb ├── dists/ │ └── focal/ │ ├── main/ │ │ └── binary-amd64/ │ │ ├── Packages.gz # apt update 读取的关键 │ │ └── Release │ └── Release └── setup-apt-source.sh # 自动写入 /etc/apt/sources.list.d/offline.list 并 apt update2.4 脚本核心逻辑自动识别目标系统并执行对应安装流install.shRHEL/CentOS和setup-apt-source.shUbuntu/Debian不是简单执行yum localinstall或apt install它们做了三件事系统指纹识别#!/bin/bash DISTRO$(awk -F /^ID/ {print $2} /etc/os-release | tr -d ) VERSION$(awk -F /^VERSION_ID/ {print $2} /etc/os-release | tr -d ) ARCH$(uname -m) echo Detected: $DISTRO $VERSION $ARCH避免在 CentOS 7 上误用 RHEL 8 的包glibc 版本不兼容直接崩溃。本地 repo 挂载与优先级设置# RHEL/CentOS: 创建 repo 文件并禁用其他源 cat /etc/yum.repos.d/offline-gcc.repo EOF [offline-gcc] nameOffline GCC Repo baseurlfile:///path/to/gcc-offline-rhel8-x86_64/baseos enabled1 gpgcheck0 priority1 EOF # 关键priority1 确保 yum 优先从此源找包避免回退到网络源原子化安装与验证# 安装后立即验证关键能力 if ! gcc --version /dev/null; then echo ERROR: gcc binary not found after install 2 exit 1 fi if ! gcc -xc -E - /dev/null /dev/null 21; then echo ERROR: cpp preprocessor failed 2 exit 1 fi if ! gcc -xc -E - /dev/null /dev/null 21; then echo ERROR: g preprocessor failed 2 exit 1 fi echo ✅ GCC toolchain verified: basic compile, cpp, g preproc OK3. aarch64 国产化平台离线包飞腾、鲲鹏、海光芯片的 GCC 交叉编译链预置方案3.1 为什么国产 CPU 服务器不能直接用 x86_64 的 GCC 包——ABI、指令集、系统调用的三重隔离某信创项目交付中工程师把 x86_64 的gcc-11.4.1.rpm直接rpm -ivh到飞腾 D2000aarch64服务器上报错error: Failed dependencies: libc.so.6(GLIBC_2.14)(64bit) is needed by gcc-11.4.1-2.1.el8.x86_64 libm.so.6(GLIBC_2.29)(64bit) is needed by gcc-11.4.1-2.1.el8.x86_64这不是版本号问题是x86_64和aarch64是完全不同的二进制格式。libc.so.6在 aarch64 上路径是/lib64/libc.so.6但符号表symbol table和重定位方式relocation type与 x86_64 不兼容。更关键的是飞腾/鲲鹏服务器用的不是标准 glibc而是经过国产化加固的glibc-kernel-5.10其syscalls表与上游 glibc 有差异。因此离线包必须严格匹配CPU 架构aarch64非arm64虽等价但 RPM 包名规范用aarch64内核版本如kernel-5.10.0-1064-oemUbuntu 22.04 鲲鹏定制版glibc 分支glibc-2.31-0ubuntu9.10-kunpeng华为定制版。我们提供的gcc-offline-kylinv10-aarch64/包含gcc-11.3.0-1.ky10.aarch64.rpm麒麟 V10 SP1 飞腾版gcc-c-11.3.0-1.ky10.aarch64.rpmglibc-2.28-153.ky10.aarch64.rpm麒麟定制 glibcglibc-devel-2.28-153.ky10.aarch64.rpmkernel-headers-5.10.0-1064-oem-1064.1064.ky10.aarch64.rpm提供asm/unistd.h等内核头3.2 交叉编译链离线包为 ARM64 设备编译固件的“前置弹药”很多嵌入式团队需要在 x86_64 开发机上为 ARM64 设备如边缘网关编译固件但开发机又不能联网。此时需要的是aarch64-linux-gnu-gcc交叉工具链而非原生gcc。我们的离线包额外提供cross-gcc-aarch64-linux-gnu/目录cross-gcc-aarch64-linux-gnu/ ├── bin/ │ ├── aarch64-linux-gnu-gcc │ ├── aarch64-linux-gnu-g │ └── aarch64-linux-gnu-objdump ├── aarch64-linux-gnu/ │ ├── include/ # 交叉编译专用头文件不含 host 系统头 │ └── lib/ # 交叉 libcmusl 或 glibc-arm64 └── install-cross.sh # 解压即用自动配置 PATH注意此包不依赖目标设备系统只依赖开发机x86_64的 glibc。安装后执行export PATH/path/to/cross-gcc-aarch64-linux-gnu/bin:$PATH aarch64-linux-gnu-gcc -v # 显示 Target: aarch64-linux-gnu3.3 麒麟 V10 / 统信 UOS 离线安装实测从空白系统到cmake make全流程以麒麟 V10 SP1飞腾 FT-2000/4为例完整部署步骤上传离线包将gcc-offline-kylinv10-aarch64.tar.gz传至服务器/opt/offline/解压并进入目录tar -xzf gcc-offline-kylinv10-aarch64.tar.gz -C /opt/offline/ cd /opt/offline/gcc-offline-kylinv10-aarch64/执行安装脚本自动适配麒麟源sudo bash install.sh # 输出 # Detected: kylin 10 aarch64 # ✅ Created /etc/yum.repos.d/kylin-offline.repo # ✅ Running: yum localinstall -y baseos/Packages/*.rpm appstream/Packages/*.rpm # ✅ Verified: gcc --version 11.3.0 # ✅ Verified: gcc -xc -E - /dev/null /dev/null验证 CMake 构建能力这是业务上线关键指标# 编译一个最小 CMake 项目 mkdir /tmp/test-cmake cd /tmp/test-cmake cat CMakeLists.txt EOF cmake_minimum_required(VERSION 3.10) project(test LANGUAGES C) add_executable(hello hello.c) EOF cat hello.c EOF #include stdio.h int main() { printf(Hello from Kylin V10 aarch64!\n); return 0; } EOF cmake . make ./hello # 输出Hello from Kylin V10 aarch64!4. 避坑GCC 离线安装的五个“看似成功实则埋雷”的典型现象4.1 现象gcc --version成功但./configure报错C compiler cannot create executables原因gcc二进制存在但glibc-devel未安装缺少/usr/include/stdio.h或libgcc运行时库未被ldconfig加载/usr/lib64/libgcc_s.so.1存在但不在ld.so.cache中。解决检查头文件ls -l /usr/include/stdio.h若不存在补装glibc-devel检查运行时库ldconfig -p | grep libgcc若无输出手动执行sudo ldconfig /usr/lib64验证链接gcc -o test test.c ./testtest.c仅含int main(){return 0;}。4.2 现象g --version正常但编译 C11 代码报错error: ‘to_string’ is not a member of ‘std’原因libstdc-devel未安装提供 C 标准库头文件或libstdc.so.6版本过低GCC 11 需libstdc.so.6.0.29旧版无std::to_string实现。解决查看libstdc版本strings /usr/lib64/libstdc.so.6 | grep GLIBCXX确认含GLIBCXX_3.4.29若缺失补装libstdc-devel和对应libstdcRPM强制更新缓存sudo ldconfig -v | grep stdc。4.3 现象make命令存在但./configure报错checking for GNU M4... no原因autoconf/automake/m4/libtool等构建工具未随 GCC 一起安装RHEL 的gcc包不依赖m4需显式安装。解决在离线包中补全appstream/Packages/下的m4-1.4.18-8.el8.aarch64.rpmautoconf-2.69-38.el8.noarch.rpmautomake-1.16.2-5.el8.noarch.rpmlibtool-2.4.6-33.el8.aarch64.rpm并在install.sh中加入yum localinstall -y appstream/Packages/{m4,autoconf,automake,libtool}*.rpm4.4 现象Ubuntu 离线安装后apt update失败报错The repository file:/... focal Release does not have a Release file原因dists/focal/Release文件缺失或Packages.gz未生成apt拒绝信任本地源。解决确认dists/focal/Release存在内容可极简echo Origin: Offline dists/focal/Release echo Label: Offline GCC Repo dists/focal/Release echo Suite: focal dists/focal/Release echo Codename: focal dists/focal/Release echo Date: $(date -R) dists/focal/Release echo Architectures: amd64 arm64 dists/focal/Release echo Components: main dists/focal/Release echo Description: Offline GCC toolchain dists/focal/Release确保dists/focal/main/binary-amd64/Packages.gz由gzip -k Packages生成非gzip Packages。4.5 现象安装后gcc -dumpmachine返回x86_64-redhat-linux但目标机是 aarch64原因误用了 x86_64 的离线包如gcc-offline-rhel8-x86_64/在 aarch64 机器上执行install.sh脚本未做架构校验强行安装了错误架构的 RPM。解决立即卸载rpm -qa | grep -E (gcc|glibc|mpfr|gmp) | xargs rpm -e --nodeps重新下载gcc-offline-kylinv10-aarch64/或gcc-offline-ubuntu2204-arm64/永久规避修改install.sh开头加入硬校验TARGET_ARCHaarch64 if [ $(uname -m) ! $TARGET_ARCH ]; then echo FATAL: This offline package is for $TARGET_ARCH, but system is $(uname -m) exit 1 fi5. 进阶验证用一个真实开源项目OpenSSL 3.0完成端到端编译测试暴露所有隐藏依赖5.1 为什么选 OpenSSL——它是最严苛的 GCC 离线环境压力测试仪OpenSSL 3.0 的构建流程堪称“GCC 依赖地狱”./Configure阶段调用perl解析模板、gcc -E预处理crypto/evp/evp_enc.c、nm检查符号、ar打包静态库make depend阶段调用makedepend已废弃现代 OpenSSL 用gcc -MM替代生成头文件依赖make build_sw阶段链接libcrypto.so.3时需libdl.so.2dlopen、libpthread.so.0线程、libz.so.1压缩最终make install需install命令来自coreutils但常被忽略。如果 OpenSSL 能离线编译通过90% 的 C/C 项目都没问题。我们用它来验证离线包的完整性。5.2 完整 OpenSSL 3.0.13 离线编译流程以 CentOS Stream 8 aarch64 为例步骤 1准备 OpenSSL 源码无需联网# 从官网下载 openssl-3.0.13.tar.gz提前下载好非离线包一部分 tar -xzf openssl-3.0.13.tar.gz cd openssl-3.0.13步骤 2检查 GCC 工具链完备性关键# 必须全部返回 0 gcc --version | grep -q 11\. || echo FAIL: gcc version gcc -xc -E - /dev/null /dev/null 21 || echo FAIL: cpp gcc -xc -E - /dev/null /dev/null 21 || echo FAIL: g cpp gcc -dumpmachine | grep -q aarch64 || echo FAIL: target arch nm --version /dev/null || echo FAIL: nm ar --version /dev/null || echo FAIL: ar install --version /dev/null || echo FAIL: install (from coreutils)步骤 3执行 Configure最易失败环节# 使用 no-shared 禁用动态库减少 libcrypto.so.3 依赖 ./Configure --prefix/opt/openssl-3.0.13 --openssldir/opt/openssl-3.0.13 no-shared linux-aarch64常见失败点及修复报错Cant locate FindBin.pm→ 缺少perl-core补装perl-core-5.26.3-419.el8.noarch.rpm报错unable to find ar→ 补装binutils-2.30-113.el8.aarch64.rpm报错cannot find -lz→ 补装zlib-devel-1.2.11-22.el8.aarch64.rpm注意是-devel非zlib。步骤 4编译与安装make -j$(nproc) # 并行编译检验多线程稳定性 # 若报错/usr/bin/ld: cannot find -ldl → 补装 glibc-devel # 若报错undefined reference to pthread_create → 补装 glibc-devel sudo make install步骤 5终极验证用新 OpenSSL 编译一个小程序// test-openssl.c #include openssl/ssl.h #include stdio.h int main() { SSL_library_init(); printf(OpenSSL %s loaded\n, OpenSSL_version(SSLEAY_VERSION)); return 0; }# 编译强制使用新 OpenSSL gcc -I/opt/openssl-3.0.13/include test-openssl.c \ -L/opt/openssl-3.0.13/lib -lcrypto -lssl -ldl -lpthread \ -Wl,-rpath,/opt/openssl-3.0.13/lib \ -o test-openssl ./test-openssl # 输出OpenSSL 3.0.13 loaded5.3 一份 OpenSSL 编译失败日志的诊断速查表错误日志片段根本原因离线包中应补的 RPMCant locate Getopt/Std.pmPerl 模块缺失perl-Getopt-Std-1.12-419.el8.noarch.rpmfatal error: openssl/opensslconf.h: No such file or directoryOpenSSL 头文件未生成Configure 未完成检查./Configure是否成功非缺包undefined reference to BIO_f_ssllibssl.so未链接补openssl-libs-3.0.13-1.el8.aarch64.rpm注意这是运行时库非开发包error while loading shared libraries: libssl.so.3: cannot open shared object fileLD_LIBRARY_PATH未设或rpath未嵌入编译时加-Wl,-rpath,/opt/openssl-3.0.13/libmake: *** No rule to make target build_sw. Stop.make depend失败导致 Makefile 不完整检查perl和gcc -MM是否可用5.4 从那以后我每次交付离线环境都强制走一遍 OpenSSL 编译验证不是为了炫技是吃过太多亏有一次给某高校实验室部署 50 台无网教学机gcc --version全部通过hello.c编译成功结果学生第一节课就要编译nginx卡在./configure: error: SSL modules require the OpenSSL library.—— 原来openssl-develRPM 被漏掉了而gcc本身不依赖它。从那以后我所有离线包交付前都必须跑通 OpenSSL 的./Configure make make install ./test-openssl四步。这成了我的“后悔药开关”只要 OpenSSL 过我就敢签验收单只要它不过哪怕gcc能打印“Hello World”我也当它没装。因为 OpenSSL 的依赖树就是 GCC 生态的真实缩影——它不放过任何一个隐藏的.so、.h、甚至perl模块。希望帮到你。本文还有配套的精品资源点击获取