资讯详情

资讯详情

Ubuntu 18.04离线安装GCC7:dpkg依赖顺序与update-alternatives配置指南

简介这份资源面向在 Ubuntu 18.04 环境下需要离线部署 GCC 编译工具链的开发者和运维人员尤其适合内网服务器、无外网条件的实验环境或需要固定编译器版本的项目场景。压缩包共 25 个文件以 24 个 deb 安装包和 1 个 sh 脚本为主整体约 20.05MBdeb 包覆盖 gcc-7、cpp-7、binutils 及 libasan4、libgomp1、libquadmath0 等运行与开发依赖库脚本则用于批量安装与依赖顺序处理省去逐条手动执行的麻烦。目前已有 3205 人学习下载说明该离线方案在同类需求中具备一定参考价值。借助这份资源读者可在无网络环境中一次性补齐 GCC 7.3 所需的编译器、链接器与底层库避免因依赖缺失导致的安装中断同时通过脚本快速完成部署为后续 C/C 项目编译、课程实验或生产环境搭建提供稳定可复用的工具链基础。1. 从 ubuntu18.04gcc.zip 说起老系统上装 GCC7 到底在解决什么问题如果你手上有一台跑着 Ubuntu 18.04 的机器可能是实验室的工控机、公司内网的编译服务器或者一块开发板的配套环境那你大概率遇到过这个场景系统自带的 GCC 版本是 7.5.0但某个 SDK、某个内核模块、某份第三方源码偏偏要求 GCC 7 的特定小版本或者你apt install gcc之后发现装上的还是旧的gcc --version纹丝不动。ubuntu18.04gcc.zip 这个包本质上就是一份围绕 Ubuntu 18.04 GCC7 的离线安装资源集合把 dpkg 安装所需的 deb 包、依赖顺序、以及绕开 apt 在线源的操作路径打包在一起。它解决的不是「GCC 是什么」这种问题而是「在没有稳定外网、源又 404 的老系统上怎么把 GCC7 干净地装进去」。适合谁适合那些不能随便升级系统、又必须凑齐编译工具链的一线开发和运维。下面我按实际拆包和复现的顺序把这份资源怎么用、参数怎么设、坑在哪讲清楚。2. 拆开 ubuntu18.04gcc.zipdpkg 离线安装 GCC7 的完整路径拿到压缩包之后别急着解压就dpkg -i *.deb那样十有八九会卡在依赖上。这一章先把包里的东西理清楚再走一遍可复现的安装流程。2.1 包内结构与 GCC7 在 Ubuntu 18.04 上的版本对应关系Ubuntu 18.04 的默认源里gcc指向的是 7.5.0-3ubuntu1~18.04这是 GCC 7 系列在 bionic 上的最终版本。很多资料里说的「GCC7」落到 Ubuntu 18.04 就是这一支。ubuntu18.04gcc.zip 里通常包含这几类文件gcc-7、gcc-7-base、cpp-7、libgcc-7-dev、libgcc1、libstdc-7-dev、g-7等 deb 包外加一份安装顺序说明或脚本。判断包是否完整最直接的办法是解压后列一遍unzip ubuntu18.04gcc.zip -d gcc7-offline cd gcc7-offline ls -1 *.deb | sort逻辑说明unzip -d指定解压目录避免污染当前路径ls -1 *.deb | sort把 deb 包按名字排序方便你对照依赖关系。参数上-1是每行一个文件sort让输出稳定便于比对。如果列出来的包少于 8 个大概率缺libgcc-7-dev或libstdc-7-dev后面编译 C 会报头文件找不到。这里有个版本对应的关键点gcc-7-base提供的是基础运行时libgcc1是 GCC 的底层支持库libgcc-7-dev才是开发头文件和静态库。很多人只装gcc-7和g-7结果#include stdint.h都过不去就是漏了 dev 包。2.2 用 dpkg 按依赖顺序安装而不是一把梭离线装 GCC7 的正确姿势是「先底层后上层」。我一般按这个顺序走sudo dpkg -i gcc-7-base_*.deb sudo dpkg -i libgcc1_*.deb sudo dpkg -i libgcc-7-dev_*.deb sudo dpkg -i cpp-7_*.deb sudo dpkg -i gcc-7_*.deb sudo dpkg -i libstdc-7-dev_*.deb sudo dpkg -i g-7_*.deb逻辑说明dpkg -i是直接安装本地 deb不走 apt 的依赖解析所以顺序错了就会报dependency problems。先装 base 和 libgcc1是因为后面所有包都依赖它们cpp-7是预处理器gcc-7依赖它g-7依赖gcc-7和libstdc-7-dev。参数上*.deb通配符要确保当前目录只有对应版本的包否则可能匹配到多个版本导致冲突。装完验证gcc-7 --version g-7 --version如果输出gcc-7 (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0说明装上了。注意命令是gcc-7而不是gcc因为系统里可能还有别的版本直接覆盖gcc软链是另一个坑后面讲。2.3 让 gcc 默认指向 GCC7update-alternatives 的用法与边界装好之后gcc还是旧版本这是热搜里「gcc升级后为啥还是旧版本」的典型现象。原因是 Ubuntu 用update-alternatives管理多版本/usr/bin/gcc是个软链。要切换sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 70 \ --slave /usr/bin/g g /usr/bin/g-7 sudo update-alternatives --config gcc逻辑说明--install注册一个候选最后的70是优先级数字越大越优先--slave让 g 跟着 gcc 一起切避免只切了 C 编译器、C 还是旧的。--config gcc会列出所有候选让你选。参数上优先级不是必须 70只要比现有的大即可但别设成 100 以上去压系统关键项。提示如果update-alternatives --config gcc里看不到 gcc-7说明上一条--install没执行成功检查路径/usr/bin/gcc-7是否存在。这一步做完gcc --version才会真正变成 7.5.0。很多人卡在这里以为包没装上其实是软链没切。3. 依赖报错与源 404离线安装 GCC7 的排错手册离线装 GCC 最烦的不是装不上而是报错信息看不懂。这一章把常见翻车场景拆开按「现象 → 原因 → 解决」走一遍。3.1 依赖报错dpkg 说 libc6 版本不够怎么办现象dpkg -i gcc-7_*.deb报gcc-7 depends on libc6 ( 2.27); however version of libc6 is 2.27-3ubuntu1看起来版本够却还是报错。原因Ubuntu 18.04 的 libc6 是 2.27-3ubuntu1而某些从别的源抓来的 GCC7 deb 是按更高 libc6 编译的版本号比较时2.27-3ubuntu1被认为小于2.27。这是 dpkg 版本比较的玄学不是真的缺库。解决优先用 Ubuntu 18.04 官方 bionic 源里的 GCC7 deb别混用 20.04 或 22.04 的包。如果已经混了用dpkg -i --force-depends强行装风险很大可能让系统库不一致。稳妥做法是apt-get install -f尝试修复但离线环境下这条命令会去联网所以更推荐重新找匹配 bionic 的包。3.2 源 404apt update 报 Release 文件过期现象sudo apt update报404 Not Found或Release file is not valid yet热搜里「ubuntu更新源404问题处理」说的就是这个。原因Ubuntu 18.04 已过标准支持期部分镜像站把 bionic 移到了 old-releases或者本地sources.list还指向已下线的地址。解决把/etc/apt/sources.list里的archive.ubuntu.com换成old-releases.ubuntu.com或者直接用 ubuntu18.04gcc.zip 里的离线包绕开源。改源前先备份sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i s/archive.ubuntu.com/old-releases.ubuntu.com/g /etc/apt/sources.list sudo apt update逻辑说明sed -i原地替换g表示全局替换。参数上如果用的是国内镜像把域名换成对应 old-releases 镜像即可。这一步只解决源可达性不解决 GCC7 安装本身但能让apt-get install -f有机会补依赖。3.3 装完 gcc 还是旧版本软链与 PATH 的优先级现象dpkg -l | grep gcc-7显示已安装但gcc --version还是 7.4 或 5.4。原因要么update-alternatives没配要么 PATH 里/usr/local/bin下有另一个 gcc 抢先。解决先which -a gcc看所有 gcc 路径再echo $PATH看顺序。如果是/usr/local/bin/gcc抢先要么删掉它要么把/usr/bin提前。如果是 alternatives 没配回到 2.3 节执行--install。这里有个血泪经验别直接ln -sf /usr/bin/gcc-7 /usr/bin/gcc那样会绕过 alternatives下次装别的版本又乱。3.4 编译 C 报找不到头文件libstdc-7-dev 漏装现象g-7能跑但编译带iostream的代码报fatal error: iostream: No such file or directory。原因只装了g-7没装libstdc-7-dev。g 本身只是驱动标准库头文件在 dev 包里。解决补装libstdc-7-dev_*.deb再dpkg -i一次。验证echo #include iostream int main(){std::coutokstd::endl;} t.cpp g-7 t.cpp -o t ./t逻辑说明这段代码只依赖标准库能编译并输出 ok 就说明头文件和链接都齐了。参数上-o t指定输出名保证编译成功才运行。3.5 多版本共存时 make 选错编译器现象系统里有 gcc-5、gcc-7make时用了 gcc-5报语法不支持。原因Makefile 里写死CCgcc而gcc软链指向旧版本。解决要么切 alternatives要么在 make 时显式指定make CCgcc-7 CXXg-7。更稳的做法是在项目 Makefile 里写CC ? gcc-7让环境变量可覆盖。参数上?表示未定义才赋值方便 CI 里替换。4. 把 GCC7 用起来编译参数、多版本隔离与验证装好只是第一步真正落地要能让项目用上它。这一章讲怎么在不动系统默认的前提下让特定项目走 GCC7。4.1 用环境变量做项目级编译器隔离最干净的做法是不切全局 alternatives而是在项目里指定。常见做法是在项目根目录放一个env.shexport CC/usr/bin/gcc-7 export CXX/usr/bin/g-7 export PATH/usr/bin:$PATH逻辑说明CC和CXX是 autotools、CMake 默认读取的变量PATH前置/usr/bin防止/usr/local/bin里的旧编译器抢先。参数上路径写绝对路径比写gcc-7更稳避免 PATH 变化导致找不到。执行source env.sh后再make整个项目就用 GCC7 了退出终端即失效不影响系统。4.2 CMake 项目指定 GCC7 的两种写法CMake 项目有两种指定方式。第一种在命令行cmake -DCMAKE_C_COMPILER/usr/bin/gcc-7 \ -DCMAKE_CXX_COMPILER/usr/bin/g-7 ..第二种在CMakeLists.txt开头set(CMAKE_C_COMPILER /usr/bin/gcc-7) set(CMAKE_CXX_COMPILER /usr/bin/g-7)逻辑说明命令行方式优先级高适合临时切换写进 CMakeLists 适合固定工具链的项目。参数上CMAKE_C_COMPILER必须在project()之前设置才生效写在后面会被 CMake 忽略这是常见翻车点。4.3 验证 GCC7 是否真正生效三个检查点装完别只看--version要验证它真能编译目标代码。三个检查点检查项命令预期结果版本gcc-7 -dumpversion7预处理器gcc-7 -E -x c /dev/null -v输出里含 gcc-7 路径实际编译gcc-7 -c test.c -o test.o生成 test.o 无报错逻辑说明-dumpversion只输出主版本号比--version干净-E -x c /dev/null让预处理器跑空文件-v打印搜索路径能看出头文件从哪来实际编译验证链接前的目标文件生成。参数上-c只编译不链接适合快速验证。4.4 用 GCC7 编译内核模块或开发板代码的注意点热搜里「ch32v在gcc编译器下定义中断函数」这类需求本质是用 GCC 的__attribute__或特定段属性。GCC7 对__attribute__((interrupt))的支持和后续版本有差异RISC-V 工具链尤其明显。如果 ubuntu18.04gcc.zip 里的 GCC7 是 x86 原生版它不能直接编 RISC-V 目标码需要交叉工具链。判断方法gcc-7 -dumpmachine输出x86_64-linux-gnu就是原生编开发板代码会报架构不匹配。解决是找对应的gcc-riscv64-unknown-elf或厂商工具链别指望原生 GCC7 通吃。参数上-dumpmachine输出目标三元组是判断交叉能力最快的方式。5. 老系统工具链的长期维护我的固定习惯Ubuntu 18.04 已经进入尾声GCC7 也不会再有新特性但很多产线环境还得靠它撑几年。我自己的习惯是把 ubuntu18.04gcc.zip 解压后的 deb 包按依赖顺序重命名比如01-gcc-7-base.deb、02-libgcc1.deb这样下次换机器直接for f in $(ls 0*.deb); do dpkg -i $f; done就能按序装完不用再翻文档。这个脚本我一般写成#!/bin/bash set -e for f in $(ls [0-9][0-9]-*.deb | sort); do echo installing $f sudo dpkg -i $f done sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 70 \ --slave /usr/bin/g g /usr/bin/g-7逻辑说明set -e让任何一步失败就停避免装一半ls [0-9][0-9]-*.deb | sort按编号顺序安装最后统一配 alternatives。参数上编号用两位数字保证 10 以后排序不乱。这个脚本我放在离线包的根目录和 deb 一起归档换机器时整包拷过去就能跑。还有一个习惯是每次装完都跑一遍dpkg -l | grep -E gcc-7|g\\-7|libgcc-7把输出存成installed.txt放进包里。下次别人问「你这包装了啥」直接甩文件不用回忆。从那以后我每次整理离线工具链包都强制走一遍「解压 → 排序 → 按序装 → 验证 → 存档」这五步再没出现过装到一半依赖崩掉的情况。希望帮到你。本文还有配套的精品资源点击获取
觉得有用,分享给同行:

为您的企业打造数字门面

稳重轻奢商务风格,端正雅致视觉,长效耐看不易过时。

立即咨询 →