gcc 入门到排错：四步编译、安装、Makefile 与版本切换

简介面向Linux使用者、C/C入门开发者以及需要系统掌握编译工具链的软件技术人员以GCC为线索讲解从源代码到可执行程序的完整编译流程。内容覆盖GCC发展历史、GCC在开源软件中的核心地位、多语言与多平台支持、预处理/编译/汇编/链接四阶段以及GCC与G之间的常见误区辨析并结合源码实例说明后缀对语言解释的影响、__cplusplus宏的作用、链接阶段的工具选择与extern C命名规则帮助读者减少命令行编译中的困惑。包体积约60KB共1个PDF文档内容精炼、篇幅紧凑可离线反复阅读。已有250人学习下载。资源虽小但知识点密度较高不仅给出gcc和g在编译与链接时的正确用法还通过汇编符号等试验对比帮助读者避开典型错误适合当作编译入门笔记反复查阅。1. 入门 gcc编译是每个 Linux 工程师绕不过去的第一课在一台刚装好的 Ubuntu 上跑 make十有八九会卡在第一步gcc 没装或者仓库里只有一个老版本C 代码一编译就是一堆 warning 和 error。gcc 是 Linux 下把 C/C 源码变成可执行文件的事实标准工具链从运维脚本、服务端中间件到嵌入式固件几乎都靠它吃饭。这篇笔记不打算把 man 手册抄一遍而是按四步编译 → 安装 → 工程化 → 版本切换 → 排错这条路把高频命令、参数和翻车现场写清楚。适合刚入门 Linux 编程的学生以及被编译问题折腾过的运维、嵌入式工程师。gcc 你躲不掉与其每次百度拼命令不如花半天把它的脾性摸透。2. 从源码到可执行文件gcc 四步编译和必须吃透的参数gcc 把一个 .c 文件变成可执行文件不是一步到位的。它内部要经过预处理、编译、汇编、链接四步。这四步在 Linux 下的地位相当于 MSVC 在 Windows、clang 在 macOS 上的角色理解了这套模型以后换 clang 也几乎零成本。平时你只敲一条 gcc 命令是因为编译器把四步串起来了。但排错的时候必须能随时叫停任意一步看中间产物长什么样。2.1 一条命令看清四步-E、-S、-c 和链接各产出什么先写一个最小的 C 文件然后分四步手动走一遍。这里故意用最啰嗦的写法是为了让你看清每一步的输入和输出。// min.c #include stdio.h #define VALUE 42 int main(void) { printf(value%d\n, VALUE); return 0; }接下来在终端里逐步执行每一步停一下用file或直接cat看产物类型# 第一步预处理展开 #include 和 #define生成 .i 文本文件 gcc -E min.c -o min.i # 第二步编译把 .i 翻译成汇编生成 .s 文本文件 gcc -S min.i -o min.s # 第三步汇编把 .s 变成机器码目标文件 .o此时还不能运行 gcc -c min.s -o min.o # 第四步链接把 .o 和系统库合并生成可执行文件 gcc min.o -o min-E只做预处理产物min.i里能看到#include stdio.h被展开了几百行VALUE被替换成 42。-S生成汇编min.s这是排查编译器优化问题时的第一现场。-c生成目标文件min.o它是二进制但还没有链接地址所以不能直接执行。最后的链接把min.o和 glibc 的启动代码、动态库解析逻辑合并在一起才有真正的可执行文件。-o指定输出文件名不加-o时 gcc 默认输出a.out。这三步中间产物各自的用途简单整理如下参数产物内容排错用途-E.i预处理后的源码检查宏展开、头文件是否被意外包含-S.s汇编源码看优化后的指令、函数调用方式-c.o目标文件确认单文件编译是否通过便于分开链接实际操作中没人会四步分开跑但你要知道-E、-S、-c各自停在哪个阶段。后面第 6 章还会用-save-temps把这四步的中间产物一次全留到磁盘上排错效率能高一大截。2.2 高频参数对照从 -Wall 到 -I/-L/-l/-D 怎么写才不踩坑入门 gcc 最怕的就是背参数表。与其硬记不如先把下面这条命令吃透它覆盖了日常 80% 的编译场景# 常见做法开警告、带调试信息、开 O2 优化指定 C11 标准 gcc -Wall -Wextra -g -O2 -stdc11 main.c -o app-Wall不是打开所有警告而是打开一组常见警告-Wextra再补一批更细的比如未使用的参数、隐式类型转换。-g生成调试信息是 gdb 能看源码、看变量值的前提发布时可以不带上。-O2是优化档位-O0不优化、-O1基本优化、-O2常用、-O3激进优化但可能引入难以定位的问题嵌入式交叉编译常选-Os控体积。-stdc11告诉编译器按哪个 C 标准来老项目可能需要-stdgnu99才能过。再往下是工程里每天都要用的四个路径和宏参数# -I 指定头文件搜索目录-L 指定库文件目录-l 指定库名-D 预定义宏 gcc main.c -I./include -L./lib -lmystuff -DDEBUG -o app-I./include告诉 gcc 去 include 目录找头文件否则#include mystuff.h只会搜当前目录和系统目录。-L./lib指定.so或.a库存放的目录。-lmystuff会自动去找libmystuff.so或libmystuff.a不需要你写全名。-DDEBUG相当于在源码最顶部写#define DEBUG常用于编译期开关日志或特性。这里先埋一个伏笔-l和-L的位置有讲究。很多人把库链接写在源文件前面结果编译报undefined reference看起来像库没找到其实是链接顺序问题。具体机制和解决办法放在第 4 章专门讲那是 gcc 新手翻车率最高的地方之一。3. Ubuntu、CentOS 和 Kylin 装 gcc源码编译 gcc 12 与下载提速3.1 用包管理器装 gccUbuntu 的 build-essential 和 CentOS 7.9 的 yum不同发行版装 gcc 的方式不一样但思路一致先更新索引再装编译工具链元包最后验证版本。# Ubuntu / Debian 系一次装齐 gcc、g、make 和基础库 sudo apt update sudo apt install -y build-essential gcc --versionbuild-essential是一个元包依赖里包含 gcc、g、make、libc-dev 等一整套编译必需品。只装gcc不带build-essential也可以但很快会遇到缺make、缺头文件的问题所以直接装元包更省事。# CentOS 7.9 用 yumCentOS 8 换成 dnf包名是 gcc 和 gcc-c sudo yum install -y gcc gcc-c make gcc --versionCentOS 系的包名比 Ubuntu 更直白C 编译器叫gccC 编译器叫gcc-c缺哪个补哪个。CentOS 7.9 仓库里的默认版本是 4.8.5非常老很多新项目编译不过所以 CentOS 7 用户经常要走 3.2 节的源码编译路线或者借助第三方软件集装新版本。Kylin V10 比较特殊它有基于 Debian 和基于 CentOS 的两种变体。动手前先执行cat /etc/os-release看 ID 是ubuntu还是centos再决定用apt还是yum。本质上它就是对应系的包管理方式不要凭感觉猜。3.2 仓库版本太老怎么办源码编译 gcc 12 到 /opt/gcc-12当系统仓库里的 gcc 版本老到无法编译新代码时比如 CentOS 7 的 4.8.5 编不了 C17 项目常见做法就是源码编译一个新版 gcc。以编译 gcc 12 为例先强调一个坑gcc 7 之后编译 gcc 源码必须先准备好 GMP、MPFR、MPC 这三个数学库否则 configure 阶段直接报错。# 解压 gcc-12 源码包和三个依赖包然后把依赖软链进 gcc 源码目录 tar -xf gcc-12.tar.xz tar -xf gmp-6.2.1.tar.xz tar -xf mpfr-4.1.0.tar.xz tar -xf mpc-1.2.1.tar.xz ln -s /path/to/gmp-6.2.1 gcc-12/gmp ln -s /path/to/mpfr-4.1.0 gcc-12/mpfr ln -s /path/to/mpc-1.2.1 gcc-12/mpc cd gcc-12 ./configure --prefix/opt/gcc-12 --disable-multilib --enable-languagesc,c make -j$(nproc) sudo make installconfigure的--prefix指定安装到/opt/gcc-12不覆盖系统自带的 gcc方便以后随时切回。--disable-multilib很重要不关掉的话configure 会去检测 32 位库缺了直接失败。--enable-languagesc,c只编 C 和 C别把 Objective-C、Fortran 都带上能省不少编译时间。-j$(nproc)是让 make 用满所有 CPU 核心编译这一步通常要 30 分钟到 1 小时机器差一点更久。源码编译完/opt/gcc-12/bin/gcc就是新版本。用之前注意 PATH这一步的坑在第 5 章 5.2 节专门展开装完还是旧版本多半是 PATH 和软链接的问题。3.3 下载 gcc 网速过慢怎么办换镜像源和断点续传热词里经常出现下载 gcc 网速过慢怎么办。先说结论靠重试基本没用把软件源换成国内镜像才是根治办法。Ubuntu 上直接编辑/etc/apt/sources.list把默认的海外地址替换成清华 TUNA、阿里云这类国内镜像站的对应地址然后sudo apt update。CentOS 则改/etc/yum.repos.d/下仓库文件里的baseurl同样指向国内镜像。如果你不是用包管理器而是手动下载 gcc 源码包下载中断是常事。wget支持断点续传网络不稳定时加上-c参数断了重新执行同一命令会从断点继续而不是从头再来# -c 断点续传避免下到一半白费 wget -c https://example.com/gcc-12.tar.xz换镜像源之后还是慢就检查是不是 DNS 解析到了海外节点可以临时换一个公共 DNS 再试。这一节解决的是能不能装得上的问题装完之后版本对不对、为什么切换不生效请直接跳到第 5 章那四条排查记录都是从真实机器上摸出来的血泪经验。4. 多文件工程与 Makefile把 gcc 从单文件带到真实项目4.1 从单文件到多文件先 -c 分工再链接现实中几乎没有项目是单个 .c 文件。最常见的工程结构是main.c写入口util.c和util.h写工具函数。新手习惯一条命令把几个 .c 一起编译# 一条命令完成所有文件的编译和链接简单但每次都要全量重编 gcc main.c util.c -I./include -o app这样做在小项目没问题但 .c 文件一多改一个文件就要重编所有文件编译时间线性增长。工程里更常用的是先分步编译再统一链接# 分别编译成 .o互不影响哪个文件改了只重编哪个 gcc -c main.c -o main.o -I./include gcc -c util.c -o util.o -I./include # 最后只做链接把 .o 合成可执行文件 gcc main.o util.o -o app-c只编译不链接产物是 .o 目标文件。两个 .c 文件各自编译main.c要#include util.h所以两个编译命令都要带-I./include。链接命令不需要-I因为头文件在编译阶段已经用完了。这套流程是 Makefile 的底层逻辑增量编译改谁编谁。4.2 一份能直接抄的 Makefile 模板变量、目标与隐式规则把上面的手动流程写进 Makefile就成了下面这个最小可用模板。它适用于源码在src/、头文件在include/的中小型项目。# Makefile CC : gcc CFLAGS : -Wall -Wextra -g -O2 -stdc11 CPPFLAGS : -I./include LDFLAGS : -L./lib LDLIBS : -lm OBJS : main.o util.o TARGET : app all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(LDFLAGS) $^ -o $ $(LDLIBS) %.o: %.c $(CC) $(CPPFLAGS) $(CFLAGS) -c $ -o $ clean: rm -f $(OBJS) $(TARGET)CC、CFLAGS、CPPFLAGS这些是 make 的约定变量。CC指定编译器CFLAGS是传给 C 编译器的参数CPPFLAGS专门放-I头文件路径LDFLAGS放-L库路径LDLIBS放-l库名。$表示目标文件$^表示所有依赖$表示第一个依赖。%.o: %.c是模式规则任何一个 .o 都由对应的 .c 编译而来。模板直接复制就能用但要注意两点。第一Makefile 里的命令行前面必须是 Tab不能是空格这是新手最容易踩的坑。第二命令行里可以临时覆盖变量比如make CFLAGS-O3会覆盖文件里的-O2不用改文件就能换优化等级。4.3 链接顺序那个 undefined reference 坑-l 放错位置就翻车这是 gcc 新手最容易困惑的问题库明明装好了-l也写了还是报undefined reference。摘一段典型报错现场# 反例-lmymath 写在目标文件前面链接必翻车 gcc -lmymath main.o -o app # 正例库写在目标文件后面链接才正常 gcc main.o -lmymath -o app原因要从链接器的工作方式说起。ld从左到右扫描输入文件先看到main.o把里面未定义的符号记到一张表里扫描到库时只从库里抽取能解决当前未定义符号的目标成员。如果库排在前面扫过库时表里还没有mymath的未定义符号这个库就被整体跳过等后面main.o进来再要符号库已经错过了。这就是为什么在工程里-l永远放最后LDFLAGS和LDLIBS要分开放。遇到两个库互相依赖的循环引用可以给链接命令加-Wl,--start-group和-Wl,--end-group把库包起来让链接器反复扫描但那是少数情况。日常记住一条源文件、目标文件在前-l库放最后能解决 90% 的 undefined reference。5. gcc 装完用不了的排查版本不变、安装失败、日志去哪了5.1 ubuntu 安装 gcc 失败找不到包或依赖 broken 的处理现象执行sudo apt install build-essential报Unable to locate package build-essential或者出现一堆依赖冲突gcc 始终装不上。原因最常见的是没先跑apt update软件源索引里根本没有这个包。另一种是系统里有未完成的安装状态dpkg 的锁或者 broken 依赖卡住了后续安装。解决先更新索引再修复依赖最后重新安装sudo apt update sudo apt --fix-broken install -y sudo apt install -y build-essentialapt update是刷新软件源列表不是升级软件这一步跳过会导致后面的install找不到包。--fix-broken会把残留的坏依赖处理掉经常一条命令就把系统从装什么都报错里救回来。装完用gcc --version确认版本号能正常输出。5.2 gcc 升级后为啥还是旧版本PATH 顺序和 alternatives 没接管现象源码编译安装了新版 gcc明明ls /opt/gcc-12/bin/gcc能看到但gcc --version显示的还是旧版本号。原因which gcc指向了/usr/bin/gcc因为 PATH 环境变量里/usr/bin排在/opt/gcc-12/bin前面。shell 按 PATH 顺序找第一个命名的gcc找到就不继续找了所以新版本根本没机会出场。解决先确认当前到底用的是哪个再决定用 PATH 还是用 update-alternatives# 看 gcc 实际解析到哪个路径 which gcc ls -l /usr/bin/gcc # 把新版本注册进 alternatives优先级 100 sudo update-alternatives --install /usr/bin/gcc gcc /opt/gcc-12/bin/gcc 100 sudo update-alternatives --config gcc如果只是临时用新版可以直接在命令行里/opt/gcc-12/bin/gcc --version或者把/opt/gcc-12/bin加到 PATH 最前面。但要做到系统级切换update-alternatives更干净它通过软链管理多个版本随时可以切回旧版。5.3 怎么切换 gcc 版本为 gcc-12update-alternatives 一套命令现象机器上同时装了 gcc-9 和 gcc-12想默认用 gcc-12直接改软链又怕把系统搞坏。原因/usr/bin/gcc只是一个软链接指向哪个版本由系统替代机制控制。手动 ln 软链也能改但update-alternatives更规范、可回退。解决把两个版本都注册进去再用--config选默认sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-12 60 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-9 30 sudo update-alternatives --config gcc数字 60 和 30 是优先级数值大的作为默认。执行--config后会列出所有候选输入编号即可切换。别忘了 g 也要同步处理否则会出现gcc是 12、g还是 9 的撕裂状态。可以用--slave把 g 绑在 gcc 上一起切换或者单独给 g 做同样的 install 操作。5.4 gcc 日志输出到文件编译信息被刷屏时的后悔药现象make 跑到一半输出几百行前面的 error 被冲掉了往上翻终端翻不到复制又复制不全。原因gcc 的警告和错误信息走的是标准错误输出 stderr而普通重定向只接管标准输出 stdout。单纯make build.log会把错误信息留在屏幕上日志文件里什么都没有。解决把 stdout 和 stderr 合并进同一个文件或者用tee同时输出到屏幕和文件# stdout 和 stderr 都落到 build.log make build.log 21 # 实时看输出同时留底 make 21 | tee build.log # 只看错误行快速定位 grep -n -E error:|undefined reference build.log21的意思是把 stderr 指向 stdout 当前所在的位置也就是 build.log。tee是个分叉管一份进终端、一份进文件。编译报错时用grep过滤出 error 行比在几百行输出里人工找快得多。这个手法同样适用于gcc单条命令任何编译器诊断信息都可以这样落盘留底。6. 用 -v、-E、-H 拆掉 gcc 编译黑匣子一次调试的真实还原6.1 出问题先别加参数用 -v 和 -H 看 gcc 真实做了什么遇到编译报错第一反应不是堆参数瞎试而是先看 gcc 实际做了什么。-v会打印完整的内部命令包括头文件搜索路径、链接器调用、库路径非常适合确认它到底找没找到某个头文件或库。-H则是头文件依赖追踪器每包含一个头文件就打印一行绝对路径# -v 打印完整编译过程看 LOG 里都调了哪些工具 gcc -v -c main.c -o main.o 21 | head -60 # -H 打印头文件搜索树找搜的是哪个目录里的 stdio.h gcc -H -c main.c -o main.o 21 | head -50这两个参数能快速戳穿两类玄学问题一是我明明改了头文件为什么没生效因为-H显示实际 include 的是另一个路径下的同名文件二是库路径配了为什么还找不到-v会把链接命令行原样打出来一眼就看到 -L 有没有进去、顺序对不对。6.2 用 -E 展开宏看真面目中间产物留在本地再分析宏定义排查是另一个高频场景。比如代码里#define BUFSIZE 4096但实际编译时 BUFSIZE 被别处重定义成了 512。这种问题看源码很难发现用-E展开预处理结果所有宏替换一目了然# -E 展开全部宏和头文件把预处理结果导出 gcc -E main.c -o main.i # 看某个宏最终被定义成什么 grep -n BUFSIZE main.i-E处理完的.i文件里宏已经被替换成字面值头文件内容也被完整展开。比对着源码猜快得多。排错结束后建议养成一个习惯遇到诡异的编译问题用大管家参数-save-temps把.i、.s、.o中间产物全部留在当前目录再逐个打开分析。它等于给 gcc 每一步操作都拍了快照出了事有后悔药可吃# -save-temps 保留预处理、汇编、目标文件三件套 gcc -save-temps -c main.c -o main.o我现在遇到编译问题默认路径是先用-v或-H看它到底干了什么再决定动哪一行而不是在参数里碰运气。这套方法帮我修掉过不少看似无解的疑难杂症希望帮到你。本文还有配套的精品资源点击获取