Linux下gcc/g++实战指南：从编译原理到库链接与调试排查

刚开始接触 Linux 上写 C/C++，绕不开的就是 gcc 和 g++ 这对老搭档。很多新手在编辑器里写了代码，敲下gcc却报出一堆看不懂的错误，或者在 Windows 上习惯了 Visual Studio 一键编译，转到 Linux 下连“编译器和编辑器有什么区别”都没理清，其实这些都是很典型的问题。这篇就专门聊聊 Linux 下 gcc/g++ 的完整用法，从安装、基本参数到多文件编译、链接库、调试排查，把那些手册里写得很简略、但实际写代码时天天踩的坑都翻出来说清楚。不管你是正在学 C 语言的在校生，还是刚开始接触 Linux 运维和开发的转行者，只要以后要跟 .c、.cpp 文件打交道，这篇内容都能帮你省下不少折腾时间。

我自己的经验是，gcc 这工具看起来只是个“把代码变成可执行文件”的命令，但真正把它用顺了，你会对整个程序的构建过程、链接原理都有更深的理解。下面直接进入正题。

1. gcc/g++ 的核心身份：不是编辑器，是编译器

1.1 先理清编译器与编辑器的区别

这是个老生常谈但很关键的问题。你在 Linux 里用 vim、nano，或者直接在 VSCode、CLion 里写代码，这些工具叫“编辑器”，它们的任务是让你能方便地修改文字。而 gcc/g++ 是“编译器”，它负责把你写的纯文本代码翻译成计算机能运行的机器指令。一句话概括：编辑器管“写”，编译器管“翻译”。新手最容易犯的错就是以为装了 IDE 就等于有了编译器，比如在 Windows 上装了 VSCode 就不装 gcc，结果一按运行就提示gcc不是内部或外部命令。在 Linux 上情况好一些，因为很多发行版默认带了 gcc，但有些精简版系统需要你手动安装。理解了这两者的分工，后面再遇到“找不到编译器”的报错就不会懵了。

1.2 gcc 与 g++ 到底差在哪里

gcc 原本是 GNU C Compiler，g++ 是 GNU C++ Compiler。但现在它们的底层其实都是同一个编译器套件 GCC（GNU Compiler Collection），只是 gcc 和 g++ 在编译时对源文件后缀的处理方式和自动链接的库不同。简单说，gcc 也能编译 .cpp 文件，但它不会自动链接 C++ 标准库（比如 libstdc++），也不会自动把代码按 C++ 规则编译。而 g++ 会自动做出这些处理。因此最稳妥的约定是：编译 C 语言用 gcc，编译 C++ 用 g++，交叉使用有时也能行，但没必要给自己找麻烦。

还有一个细节，当你用 gcc 编译 .c 文件时，它会按照 C 标准来解析；用 gcc 编译 .cpp 文件时，它实际也会调用 C++ 编译器前端，但链接阶段不会自动加 -lstdc++。所以有的人写 C++ 代码，用 gcc test.cpp -o test，结果报一堆“undefined reference to std::cout”之类的链接错误，原因就在这。直接用 g++ 就能避开这个问题。

1.3 GCC 在整个工具链里的位置

一个完整的 C 程序从源码到运行，要经过预处理、编译、汇编、链接四个阶段。gcc/g++ 是把这些阶段整合在一起的“总指挥”。换句话说，它不仅仅是一个“翻译官”，还会自动调用预处理器、汇编器、链接器。理解这条链路对后面看编译错误很有帮助，比如报错信息里出现 .s 文件、.o 文件，你就知道卡在哪个阶段了。

在 Linux 里，还有一个有意思的现象：很多“linux常用命令”的教程里都会把 gcc 列为一个基础命令。它确实是面试题和运维脚本里的常客，因为你写 C 插件、编译开源软件都可能要用到它。而且 Linux 本身的很多系统工具就是用 C 写的，掌握 gcc 基本使用，等于拿到了解锁开源世界的钥匙。

2. Linux 环境下安装 gcc/g++：不要盲目装

2.1 用发行版自带包管理器安装

现在的 Linux 发行版都提供预编译好的 gcc 包，直接安装就行，比从源码编译省事太多。Debian/Ubuntu 系使用 apt：

bash复制sudo apt update
sudo apt install gcc g++ make

CentOS/RHEL/Fedora 系使用 yum 或 dnf：

bash复制sudo yum install gcc gcc-c++ make
# 或者较新版本 Fedora/RHEL 9+
sudo dnf install gcc gcc-c++ make

Arch Linux 系用 pacman：

bash复制sudo pacman -S gcc make

装完之后用 gcc --version 和 g++ --version 检查一下。两个版本最好一致，避免混用带来的诡异问题。把 make 也装上是我的习惯，因为后面编译多文件时几乎一定会用 Makefile，而 GNU Make 又是 Linux 下构建的标配。

2.2 版本怎么选：默认包还是自己编译

如果只是学习和日常开发，用系统源里的 gcc 完全够。有些发行版默认带的版本可能偏老，比如 Ubuntu 22.04 默认 gcc 11，Ubuntu 24.04 默认 gcc 13，对新 C++20 特性支持已经很好。如果你的代码必须用更新的编译器，比如需要 C++23 的部分能力，可以考虑安装较新版本的 gcc。Debian/Ubuntu 上可以安装 gcc-13 这类指定版本包，或者用官方 PPA；更折腾的方式是手动从源码编译安装，我做过几次，耗时较长但能放到自定义目录。只要不涉及系统关键构建，普通场景真的没必要自己去源码编一个。

2.3 交叉编译器与专用工具链

嵌入式开发里常提到的“linux arm 交叉编译器”就是另一类东西了。交叉编译器运行在 x86 主机上，生成的是 ARM 平台的可执行文件。比如常见的 arm-linux-gnueabihf-gcc。这类工具链通常由芯片厂商或开发板社区提供，也可以从发行版仓库装：

bash复制sudo apt install gcc-arm-linux-gnueabihf

交叉编译要注意：你需要为目标平台安装对应的标准库，否则链接时报找不到 crt1.o 这类文件。单纯的“Unix 平台编译器”概念，在嵌入式世界里就变成了“宿主机+目标机”的双视角。这个坑我在玩树莓派裸机程序和板卡调试时频繁踩过，后面第5节专门展开。

3. gcc/g++ 基本用法：从零到一跑通你的程序

3.1 单文件编译最简流程

在 Linux 下写一个最简单的 C 程序，保存为 hello.c：

c复制#include <stdio.h>

int main(void) {
    printf("Hello, Linux!\n");
    return 0;
}

编译它：

bash复制gcc hello.c -o hello

执行：

bash复制./hello

这里 -o hello 是指定输出文件名。如果不加 -o，gcc 默认生成 a.out。在 Linux 社区里经常能看到 ./a.out 这个名词，其实就是“没有指定名字的产物”。我建议每次都显式写 -o，不然多个文件编译时全变成 a.out 覆盖来覆盖去，很容易乱。

C++ 程序类似：

cpp复制#include <iostream>

int main() {
    std::cout << "Hello, C++" << std::endl;
    return 0;
}

编译：

bash复制g++ hello.cpp -o hello_cpp

注意 main 函数的返回值。C 标准里 main 可以省写 return 0;，编译器会隐式补上；C++ 也是如此。但如果你写的不是 main 而是别的名字，比如写成了 mian，那编译时会直接报错。常见的英文报错是：

code复制undefined reference to `main'

或者：

code复制/usr/bin/ld: crt1.o: 在函数‘_start’中:
(.text+0x20)：对‘main’未定义的引用

看到“undefined reference to 'main'”，先检查是不是函数名拼错了，而不是急着找编译器的问题。这个错误在初学者中高频出现，我光是帮人看“编译器未包含main类型”就看过好多次了。事实上 gcc 自带不会“包含”任何 main，它就是个翻译工具，main 必须由用户自己写。有些人用某些 Windows 上的纯 IDE 用惯了，以为系统会生成一个模板，换了命令行环境就抓瞎。记住：main 是你写的，不是编译器给的。

3.2 多一个 -Wall 就多一份安全

编译的时候，强烈建议加上 -Wall，它开启大部分常见警告。比如变量声明了未使用、函数的返回值被忽略等，这些警告不会让编译失败，但能帮你抓出潜在隐患。更进一步可以加 -Wextra，它比 -Wall 严一点。我写代码时默认命令是：

bash复制gcc -Wall -Wextra -o app main.c

有些教程还推荐 -Werror，把警告当错误处理。这个适合对代码质量要求高的项目，缺点是刚开始写代码时会被一些无关紧要的警告卡住，反而打击信心。我的建议是学习阶段-Wall -Wextra即可，等能读懂所有警告后再考虑-Werror。

3.3 优化选项：O0、O2、O3 怎么选

编译器优化是很容易被忽略的话题。gcc 支持 -O0（不优化）、-O1、-O2、-O3，以及 -Os（优化体积）。Debug 阶段用 -O0 -g，方便调试；发布用 -O2 是常见选择；-O3 能再提升一点速度，但编译时间和生成的代码体积都会增加。优化不是万能的，特别是一些浮点运算或依赖运算顺序的代码，优化后可能会出现精度差异。我在做数值计算相关程序时，经常用 -O2 跑一遍，再用 -O0 跑一遍对比结果，确保逻辑一致。

-g 是生成调试信息，配合 gdb 使用。哪怕你现在不调试，也建议先加上，它不影响正常运行性能，只是生成的文件里多了一点调试符号。

3.4 预处理看细节：gcc -E

有时候你想知道宏展开、头文件包含到底发生了什么，可以只做预处理。比如：

bash复制gcc -E hello.c -o hello.i

生成的 .i 文件里包含展开后的代码，几百行甚至几千行都是正常的。这个技巧在排查复杂宏定义问题的时候特别有用。比如宏定义里少括号，导致表达式运算顺序不对，直接看展开结果是找到根源最快的路径。很多人只知道编译报错就用眼睛死盯源代码，半天找不出问题，其实展开后一眼就能看出猫腻。

3.5 编译过程分步看：让学习曲线更平缓

gcc 一条命令搞定全部四个步骤，但如果你想理解每一步，可以这样拆解：

bash复制# 1. 预处理：生成 .i
gcc -E hello.c -o hello.i
# 2. 编译：把 .i 编译成汇编 .s
gcc -S hello.i -o hello.s
# 3. 汇编：把 .s 汇编成目标文件 .o
gcc -c hello.s -o hello.o
# 4. 链接：把 .o 和库链接成可执行文件
gcc hello.o -o hello

不过更常见的快捷方式是直接从 .c 生成 .o：

bash复制gcc -c hello.c -o hello.o

这个 .o 文件就是“目标文件”，里面已经是机器码，但还没有链接库，所以不能直接运行。当你之后把多个 .o 文件一起链接时，就形成了最终程序。理解这三个文件：.i 预处理结果、.s 汇编代码、.o 目标文件，能帮你更好地读懂编译错误。

4. 多文件编译、连接动态库与静态库的实战套路

4.1 多文件编译的三种姿势

实际项目当然不只一个文件。假设你有 main.c、utils.c、utils.h。第一种姿势是一次性编译所有源文件：

bash复制gcc -Wall -o app main.c utils.c

优点简单粗暴，缺点是如果其中一个文件改了，所有文件都要重新编译一遍。大项目会等得人发疯。第二种是分开生成 .o 再链接：

bash复制gcc -Wall -c main.c
gcc -Wall -c utils.c
gcc -o app main.o utils.o

这种就具备增量编译的基础。第三种是借助 Makefile 管理依赖关系，这是大规模项目的常见做法。一个最基本的 Makefile 可以长这样：

makefile复制CC = gcc
CFLAGS = -Wall -Wextra
OBJS = main.o utils.o
TARGET = app

$(TARGET): $(OBJS)
	$(CC) -o $(TARGET) $(OBJS)

main.o: main.c utils.h
	$(CC) $(CFLAGS) -c main.c

utils.o: utils.c utils.h
	$(CC) $(CFLAGS) -c utils.c

clean:
	rm -f *.o $(TARGET)

写 Makefile 有一点要特别注意：命令行前必须是 Tab 键开头，不能用四个空格代替。这是新手最容易郁闷的问题，看起来一样的缩进，make 就是报 “missing separator”。我当年在这上面浪费过至少半小时。

4.2 头文件的搜索路径与外部依赖

如果你的项目里有 include 目录，需要使用 -I 指定头文件搜索路径：

bash复制gcc -I./include -o app main.c utils.c

如果链接第三方库，例如数学库用 -lm，线程库用 -lpthread。gcc 中 -l 后面跟库名，规则是“掐头去尾”：比如 libm.so 写 -lm，libpthread.so 写 -lpthread。库路径用 -L 指定，比如：

bash复制gcc -L./libs -lmylib -o app main.o

这里它会去找 libs/libmylib.so 或者 libmylib.a。链接顺序也有讲究：被依赖的库要放在依赖它的目标文件后面。例如 main.o 依赖 libfoo，应该写成：

bash复制gcc main.o -lfoo -o app

如果写成 gcc -lfoo main.o，在某些环境下会报 undefined reference，因为链接器是从左到右扫描符号的，先看到 libfoo 发现没有需要填充的符号，等再扫描 main.o 时符号缺失，已经来不及回填了。这个坑特别隐蔽，我见过不少项目明明静态库放在那，却一直报符号未定义的，大多就是顺序写反了。

4.3 生成和使用静态库

静态库本质是把一堆 .o 文件打包成 .a 文件。操作很简单：

bash复制gcc -c utils.c -o utils.o
ar rcs libutils.a utils.o

使用的时候：

bash复制gcc -static -o app main.c -L. -lutils

静态库会直接嵌入可执行文件里，运行时不依赖外部的 .a 文件，但文件体积大。有的发行版系统里，-static 可能需要额外的静态库支持，比如 glibc-static，否则会报找不到 crt1.o 之类的错误。如果只是为了把某个功能打包，也可以不写 -static，只把自定义的静态库链接进去，剩下的 C 库动态链接，这样兼容性更好：

bash复制gcc -o app main.c -L. -lutils

4.4 生成和使用动态库

动态库也叫共享库，Linux 下后缀是 .so（Shared Object）。生成动态库的命令：

bash复制gcc -fPIC -c utils.c -o utils.o
gcc -shared -o libutils.so utils.o

-fPIC 是生成与位置无关的代码，是链接动态库时的常用要求。然后编译主程序时链接：

bash复制gcc -o app main.c -L. -lutils

这里有个非常经典的坑：编译时链接成功了，但运行时系统提示找不到 libutils.so。这是因为动态库需要在运行时被加载器找到。解决方法有三种：

bash复制# 方法1：把库放到系统搜索路径
sudo cp libutils.so /usr/local/lib
sudo ldconfig

# 方法2：设置环境变量
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH

# 方法3：编译时指定 rpath
gcc -o app main.c -L. -lutils -Wl,-rpath,$(pwd)

我自己的习惯是先设置 LD_LIBRARY_PATH 应急，但最终发布时会把库安装到标准路径并跑一遍 ldconfig。方法3适合那种不想动系统目录、又希望可执行文件直接能找到库的场景，只是可执行文件里会写入一个绝对路径，如果目录移动了就会失效。

4.5 到底用静态库还是动态库

这里给出一张简单的对比表，方便你决策：

从经验上说，第三方库优先用动态库，因为方便共享和更新；自己项目内部封装的小代码，先用静态库简化部署也完全可以。大系统里动态库版本冲突是运维头号麻烦，两个程序依赖不同版本的同一动态库，可以把系统搞得焦头烂额。这就是为什么很多大型软件选择把依赖的库静态嵌入。

5. 编译过程中的疑难杂症与排查思维

5.1 头文件找不到：fatal error: xxx.h: No such file or directory

这类报错绝大多数发生在编译阶段，原因通常有两个：一是对应开发包没有安装。在 Ubuntu 上，只有一个库的运行时包还不够，编译时还需要带 -dev 后缀的开发包。比如 zlib1g 提供动态库，zlib1g-dev 提供头文件。安装开发包一般就能解决。二是你写的包含路径不对。如果你同行目录有一个 myheader.h，应该写 #include "myheader.h"，而不是 #include <myheader.h>。尖括号主要搜索系统路径，引号会先在当前文件所在目录搜索。记不住这个规律的，可以直接统一用双引号包含自己写的头文件。

5.2 undefined reference 到 everything：链接顺序与 C++ 名称改编

这种错误比头文件找不到更让人抓狂，因为它对应的阶段在“链接”。常见的原因包括：忘记链接对应库、链接顺序错误、C++ 代码里调用 C 库时没有加 extern "C"。最后一点是 C++ 新手特别容易踩的：你在 C 语言库里写了 int add(int, int);，用 C++ 文件直接 #include 后调用 add，链接时发现 undefined reference。原因是 C++ 编译器为了支持重载，会把函数名改编成带参数类型的符号名，而 C 语言库里的符号是原始名字。解决方案是在 C++ 代码里把引入的头文件包起来：

cpp复制extern "C" {
#include "clib.h"
}

或者在编写 C 头文件时就考虑兼容性：

c复制#ifdef __cplusplus
extern "C" {
#endif

int add(int, int);

#ifdef __cplusplus
}
#endif

这种写法在大型开源库里非常常见，理解了背后的符号规则，你就不会觉得它奇怪了。

5.3 编译器报错定位：解释器不完全等于答案

初学者看到一长串报错就很慌，其实 gcc 报错信息有规律。比如：

code复制test.c:5:12: error: undeclared identifier 'a'

意思是 test.c 文件的第5行第12列有错误，错误类型是“未声明标识符 'a'”。这时候直接跳到那行去看，比盯着终端顶部理会得多。gcc 还会给出后续的“note:”提示，有时是候选函数，有时是更具体的建议。阅读报错要从第一条开始看，不要从最后一条。很多后面的报错是因为第一条引发了连锁错误，单独修后面的没有意义。

我还有一个经验：当编译错误看着完全无从下手时，把代码里的大段代码注释掉几行，逐步压缩范围，很快就能定位到底是哪一行出了问题。这比反复读报错更高效，因为编译器面对多个错误时可能会有误导性的信息。

5.4 段错误与调试基础

编译通过只代表语法没问题，不表示运行正确。最常见的运行时崩溃是“段错误”（Segmentation fault）。原因通常是空指针访问、数组越界、栈溢出等。排查段错误最常用的工具是 gdb：

bash复制gcc -g -o app main.c
gdb ./app
(gdb) run
(gdb) bt

bt 打印调用栈，可以看到崩溃发生在哪个函数哪一行。这是一个很基础的排查技巧，但很多初学者并不知道，还在用 printf 一点点打印“这里到了吗”。如果你嫌 gdb 命令行不好用，也可以试试 cgdb，或者直接在 IDE 里集成的调试界面。重要的是思路：先拿到挂掉时的调用栈，再顺着代码往前走。

5.5 排查效率提升：利用预编译头与 ccache

当你项目规模变大，每次编译都很慢时，可以考虑 ccache。它是一个编译缓存工具，第二次编译同样代码时会直接命中缓存，显著加速。安装之后，把编译命令的 gcc 改成 ccache gcc 即可。配合 Makefile 时，在 CC 里带上 ccache 就行：

makefile复制CC = ccache gcc

这个工具体验很好，尤其在频繁 git checkout 不同分支、反复改少量代码的时候，编译时间可以从几十秒降到几秒。对嵌入式交叉编译同样有效，前提是缓存命中前首次编译需要完整做一遍。

6. gcc/g++ 高级操作与经验扩展

6.1 预处理宏与条件编译

在代码里定义宏可以通过 -D 参数：

bash复制gcc -DDEBUG -o app main.c

在代码中配合 #ifdef DEBUG 就能做到调试信息仅在加了这个参数时输出。比如：

c复制#ifdef DEBUG
printf("debug: x=%d\n", x);
#endif

这比在源码里频繁改注释方便得多。-D 参数还能传值，比如 -DVERSION=\"1.0\"。注意 shell 里的引号转义，建议用单引号包住整个参数：

bash复制gcc '-DVERSION="1.0"' -o app main.c

6.2 生成汇编代码学习底层

强烈建议初学者试试 gcc -S，生成汇编代码看看你的 C 代码到底变成了什么。比如：

bash复制gcc -S -O2 hello.c -o hello.s

打开 hello.s 你能看到 main 函数里的指令。不用完全读懂，光是感受一下底层的样子，就能建立“高级语言到机器码”的直觉。对于面试题里常考的“编译器优化”内容，这也是最直观的学习方式。有些项目为了做底层优化，会直接内联汇编，gcc 支持用 asm 把汇编嵌进 C 代码：

c复制__asm__("nop");

这种方式平时不推荐，除非你在写操作系统或性能极限模块。gcc 还提供了不少内建函数，比如字节交换 __builtin_bswap32，比手写位移快且可读性好。

6.3 交叉编译器与 C++ 可用性

前文提到了交叉编译，这里展开讲一下经验。交叉编译器的命名规则很直观：架构-厂商-操作系统-gcc。比如 arm-linux-gnueabihf-gcc 表示 ARM 架构、Linux 系统、浮点硬接口。使用起来和本地 gcc 一样：

bash复制arm-linux-gnueabihf-gcc -o app main.c

生成的可执行文件拿到 ARM Linux 板子上运行。交叉编译最大的麻烦不是编译器本身，而是依赖库都要为目标架构准备一份。比如你的代码需要 libssl，就必须安装对应的 libssl-dev:armhf 多架构包。在 Debian/Ubuntu 上可以开启多架构支持：dpkg --add-architecture armhf，然后 apt install libssl-dev:armhf。不然链接时一堆“找不到 -lssl”的报错，其实是搜索路径里没有 ARM 版的库。

6.4 现代调试与检测工具：AddressSanitizer

从 gcc 4.8 开始，GCC 集成了 AddressSanitizer（ASan），可以检测内存访问错误。编译时加上：

bash复制gcc -fsanitize=address -g -o app main.c

运行时如果越界访问或使用已释放内存，程序会打印详细报告，包括内存地址、分配的栈/堆、引发错误的位置。这是我调试 C/C++ 内存问题时最爱的工具。比起 valgrind，ASan 更轻量，而且能捕获更多问题。缺点是编译出的程序内存占用大，运行变慢，所以只用于 debug 版本。也可以启用未定义行为检测：

bash复制gcc -fsanitize=undefined -g -o app main.c

两个检测同时开也行。真实项目里，我会在 CI 脚本中额外编译一个 ASan 版本，专门跑测试，能抓住不少隐藏 bug。

6.5 从 gcc 到其他编译器的一些参考

Linux 生态里，gcc/g++ 是最常见的选择，但也不是唯一。很多人会提到 LLVM 家族的 clang/clang++，它和 gcc 参数基本兼容，报错信息更友好，编译速度有时也更快。比如：

bash复制clang -Wall -o app main.c

你完全可以把它当 gcc 的备胎用。还有“C 语言编译器”这个词在 Windows 语境下常指 MSVC，即 Visual Studio 里的 cl.exe。但 MSVC 只能在 Windows 上跑，Linux 上用不了。这里也顺带回应热词里关于“msvc编译器怎么安装”的疑问：如果你在 Linux 开发，就别折腾 MSVC 了，用 gcc/g++ 是正道；如果你在 Windows 上做 Linux 相关开发，可以考虑 WSL，在 WSL 里继续用 gcc，体验比在 Windows 原生环境里折腾 Cygwin 或 MinGW 更贴近真实生产环境。

6.6 环境变量与 gcc 行为定制

有几个环境变量会影响 gcc/g++。比如 CFLAGS 和 CXXFLAGS 是很多 Makefile 会读取的编译器参数，你可以这样设置临时生效：

bash复制export CFLAGS="-Wall -O2"
export CXXFLAGS="-Wall -O2"

在交叉编译时，CPATH 和 LIBRARY_PATH 可以指定头文件和库的搜索目录。这些环境变量有时会成为“看不见的坑”：你明明没在命令行写 -I，却莫名其妙找到了某个目录下的头文件，很可能就是 CPATH 里包含它。我排查类似诡异问题时，习惯先跑一句：

bash复制echo $CFLAGS $CPATH $LIBRARY_PATH

看看是不是有残留的环境变量影响了编译结果。

7. 我的经验总结与给初学者的几点建议

7.1 从刻意分开 compile 和 link 开始

训练初期建议不要只图快，把多文件编译拆成“先 .c 到 .o，再 .o 到可执行文件”两步操作。这样可以体会每一阶段发生的事，出链接错误时才知道去哪里找原因。有了一定感觉后，再用 Makefile 把这些自动化。

7.2 善用 -fsyntax-only 检查语法而不生成本地文件

当你只想快速确认语法对不对，不急着编译产物，可以加：

bash复制gcc -fsyntax-only main.c

没有任何输出就说明语法通过。这特别适合在脚本里批量检查多个文件。

7.3 编写可移植构建脚本时注意 CC 变量

如果你的项目要让其他人在 Linux/macOS 等平台编译，尽量不要在脚本里写死 gcc，而是使用环境变量 CC，默认值可以设成 gcc。在 Makefile 中 CC ?= gcc 是标准写法。这样别人用 clang 也能直接替换，很灵活。

7.4 最后分享一个减少抓狂的小技巧

在命令行敲 gcc 命令时，编译出错了，先把命令复制下来，把 -Wall 换成 -Wall -v。-v 会显示具体的执行步骤，包括调用了哪些子程序、搜索了哪些路径。这个输出看多了，你就对整个工具链的脾气了如指掌。我第一次用 -v 的时候才发现，原来 gcc 在背后偷偷调用了 cc1、as、collect2 这些组件，顿时感觉之前只把 gcc 当成一个“黑盒命令”实在太可惜了。

用 gcc/g++ 写代码这件事，越早突破“命令恐惧”越受益。它和 Linux 系统本身一样，规则清晰、反馈直接，只要愿意看报错、愿意试参数，用不了太久就能建立自己的体感。希望这篇分享能帮你少走一段弯路。