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、-S、-c各自停在哪个阶段。后面第 6 章还会用-save-temps把这四步的中间产物一次全留到磁盘上，排错效率能高一大截。

2.2 高频参数对照：从 -Wall 到 -I/-L/-l/-D 怎么写才不踩坑

入门 gcc 最怕的就是背参数表。与其硬记，不如先把下面这条命令吃透，它覆盖了日常 80% 的编译场景：

# 常见做法：开警告、带调试信息、开 O2 优化，指定 C11 标准 gcc -Wall -Wextra -g -O2 -std=c11 main.c -o app

-Wall不是"打开所有警告"，而是打开一组常见警告，-Wextra再补一批更细的，比如未使用的参数、隐式类型转换。-g生成调试信息，是 gdb 能看源码、看变量值的前提，发布时可以不带上。-O2是优化档位，-O0不优化、-O1基本优化、-O2常用、-O3激进优化但可能引入难以定位的问题，嵌入式交叉编译常选-Os控体积。-std=c11告诉编译器按哪个 C 标准来，老项目可能需要-std=gnu99才能过。

再往下是工程里每天都要用的四个路径和宏参数：

# -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 用包管理器装 gcc：Ubuntu 的 build-essential 和 CentOS 7.9 的 yum

不同发行版装 gcc 的方式不一样，但思路一致：先更新索引，再装编译工具链元包，最后验证版本。

# Ubuntu / Debian 系，一次装齐 gcc、g++、make 和基础库 sudo apt update sudo apt install -y build-essential gcc --version

build-essential是一个元包，依赖里包含 gcc、g++、make、libc-dev 等一整套编译必需品。只装gcc不带build-essential也可以，但很快会遇到缺make、缺头文件的问题，所以直接装元包更省事。

# CentOS 7.9 用 yum，CentOS 8+ 换成 dnf，包名是 gcc 和 gcc-c++ sudo yum install -y gcc gcc-c++ make gcc --version

CentOS 系的包名比 Ubuntu 更直白：C 编译器叫gcc，C++ 编译器叫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 编不了 C++17 项目，常见做法就是源码编译一个新版 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-languages=c,c++ make -j"$(nproc)" sudo make install

configure的--prefix指定安装到/opt/gcc-12，不覆盖系统自带的 gcc，方便以后随时切回。--disable-multilib很重要，不关掉的话，configure 会去检测 32 位库，缺了直接失败。--enable-languages=c,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 -std=c11 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-essential

apt 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-12：update-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 2>&1 # 实时看输出，同时留底 make 2>&1 | tee build.log # 只看错误行，快速定位 grep -n -E "error:|undefined reference" build.log

2>&1的意思是把 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 2>&1 | head -60 # -H 打印头文件搜索树，找"搜的是哪个目录里的 stdio.h" gcc -H -c main.c -o main.o 2>&1 | 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看它到底干了什么，再决定动哪一行，而不是在参数里碰运气。这套方法帮我修掉过不少看似无解的疑难杂症，希望帮到你。

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