第3章：编译器与工具链：GCC 源码安装

编译器是把 C++ 源码翻译成机器码的"翻译官"；当系统自带的翻译官太老、听不懂新标准时，你需要亲手从源码再培养一位

3.1 零基础铺垫：GCC 是什么：把 C++ 翻译成机器码的编译器家族

先回答一个最基本的问题：什么是编译器（compiler）？说人话，编译器就是一个"翻译官"——把人类能读懂的源码（比如 C++）翻译成 CPU 能直接执行的机器码。第 1 章讲过，C++ 是编译型语言：写好的 .cpp 文件必须先经过编译，生成可执行文件，才能运行。而这个"翻译"动作的执行者，就是本章的主角 GCC。

GCC 全称 GNU Compiler Collection（GNU 编译器集合），是 GNU 项目（GNU 是 "GNU's Not Unix" 的递归缩写，一个致力于自由软件的操作系统项目）的核心成果之一，由自由软件基金会（FSF）维护，1987 年发布第一个版本。它最初只支持 C 语言，名字叫 GNU C Compiler，后来逐渐加入 C++、Fortran、Go、Ada 等多种语言的支持，名字也随之改成了"编译器集合"。你常用的 gcc 和 g++，其实都是这一个编译器家族的成员：gcc 按 C 语言规则编译 .c 文件，g++ 按 C++ 规则编译 .cpp 文件，并且链接时会自动带上 C++ 标准库 libstdc++。

用系统分析的方法看，一个编译器的内部可以分成三段流水线：前端负责"读源码"——做词法、语法分析，把源码变成一种统一的中间表示（GCC 里叫 GIMPLE）；中端负责"做优化"——在中间表示上做各种优化（死代码消除、内联、循环优化等），这部分与具体语言和硬件都无关；后端负责"生成机器码"——把优化后的中间表示翻译成某个 CPU 架构的汇编。正因为三段分离，GCC 才能做到"多种语言前端 + 多种架构后端"的排列组合：加一种新语言只写前端，支持一种新 CPU 只写后端。

命令	角色	说人话
gcc	C 语言前端驱动	编译 C 源码
g++	C++ 语言前端驱动	编译 C++ 源码，链接时自动带 libstdc++
gfortran	Fortran 前端驱动	编译 Fortran 源码
as / ld	汇编器 / 链接器	来自 binutils 包，负责汇编与链接
libstdc++	C++ 标准库	C++ 程序运行时要依赖的标准库实现

为什么你通常感觉不到"工具链"的存在？因为 g++ 一条命令把预处理、编译、汇编、链接四步全包了。但搞清楚这几步，是后面排查一切编译问题的前提——报错发生在哪一步，问题就出在哪一类东西上。

# 用 g++ 编译 C++ 程序：一条命令完成 预处理→编译→汇编→链接
g++ hello.cpp -o hello

# 用 gcc 也能编译 C++ 文件，但链接时必须手动加 -lstdc++
gcc hello.cpp -o hello -lstdc++

# 查看 GCC 家族成员版本（-v 会打印完整的编译配置与版本号）
gcc --version
g++ --version

# 工具链的其他成员来自 binutils 包
as --version
ld --version

3.2 GCC 版本与 C++ 标准支持对照

C++ 不是一成不变的语言，它由 ISO 标准化组织维护，标准编号为 ISO/IEC 14882，大约每三年发布一个新版本：C++98（1998 年）、C++11（2011 年）、C++14（2014 年）、C++17（2017 年）、C++20（2020 年）。每发布一个新标准，编译器都要花上几年才能把它完整实现——所以"编译器版本够不够新"直接决定了你能不能用上新语法。

GCC 对 C++ 各标准的支持进度，记住下面四个里程碑就够用了：GCC 4.8（2013 年）起完整支持 C++11；GCC 5.1（2015 年）是首个完整支持 C++14 语言特性的版本；GCC 7（2017 年）引入 C++17（GCC 8 补全剩余特性）；GCC 10（2020 年）提供 -std=c++20 选项，支持 C++20 的大部分特性。还有一个容易踩的坑：默认模式永远落后于最新标准——GCC 5 的默认模式仍是 gnu++98，GCC 6 起默认 gnu++14，直到 GCC 11 才把默认改为 gnu++17。也就是说，就算你装的是新 GCC，不写 -std= 选项，它也只会按旧标准编译你的代码。

GCC 版本	发布年	完整支持的标准	开启选项
GCC 4.8.1	2013	C++11	-std=c++11
GCC 5.1	2015	C++14	-std=c++14
GCC 7	2017	C++17	-std=c++17
GCC 10	2020	C++20（大部分）	-std=c++20

# 编译时用 -std= 显式指定标准（gnu++14 表示"带 GNU 扩展的 C++14"）
g++ -std=c++14 hello.cpp -o hello
g++ -std=c++17 hello.cpp -o hello
g++ -std=c++20 hello.cpp -o hello

# 看看当前 GCC 默认按什么标准编译（GCC 5 默认 gnu++98）
g++ -dumpspecs | grep -o "std=gnu++[0-9]*" | head -1

// __cplusplus 宏：编译期告诉你当前按哪个标准编译
#include <iostream>

int main() {
    // C++11 输出 201103L，C++14 输出 201402L，C++17 输出 201703L
    std::cout << __cplusplus << std::endl;
    return 0;
}

日常排查时记住一句口诀：看到新语法报语法错误，先查两件事——编译器版本够不够新、-std= 有没有写对。比如在 GCC 4.8 上编译 C++14 代码，会直接报 cc1plus: error: unrecognized command line option '-std=c++14'——问题一目了然：不是代码错了，是"翻译官"太老。

3.3 为什么有时必须源码安装

大多数 Linux 发行版都自带 GCC，直接 sudo yum install gcc gcc-c++ 或 sudo apt install build-essential 就能用。但系统自带的编译器有一个先天局限：版本由发行版决定，且普遍偏旧。CentOS 7 自带的是 GCC 4.8.5（只完整支持 C++11），Ubuntu 16.04 自带 GCC 5.4；而不少第三方库为了提高性能、简化代码，都要求较新的编译器——比如 POCO 这类现代 C++ 库，新版本就明确要求支持 C++14 甚至 C++17 的编译器。这就是本章素材记录的原始动机："对于一些源码的编译如 poco 库，需要的 GCC 的版本要求比较高，所以需要源码编译 GCC"。

什么时候必须走源码安装？三种典型场景：第一，要用新标准——发行版只提供老编译器，而你的项目想用 C++17/C++20；第二，要特定版本——某个库或工具链要求精确的 GCC 版本（编译器版本影响 ABI 兼容性，混用不同版本编译的库可能链接失败）；第三，发行版仓库里根本没有——某些精简系统或特殊发行版不提供 GCC 包。相比之下，用 apt/yum 装的是发行版"定制过"的版本，胜在快、有依赖管理，但版本选择几乎没有余地。

维度	包管理器安装（apt/yum）	源码安装
版本选择	发行版打包的固定版本	任意版本，精确可控
安装位置	系统目录（/usr/bin）	--prefix 自定义（如 /usr/local 或 /opt/gcc-5.1.0）
耗时	几分钟	编译几十分钟到几小时
升级维护	包管理器自动处理	自己重新编译安装
适合场景	日常开发、无版本要求	新标准、特定版本、多版本共存

# 看看系统自带的 GCC 是哪个版本（CentOS 7 上是 4.8.5）
gcc --version
# gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)

# 想用 C++14？老编译器直接拒绝：
g++ -std=c++14 test.cpp
# cc1plus: error: unrecognized command line option '-std=c++14'

# 源码安装 GCC 前，先确认"能编译编译器的编译器"存在（自举 bootstrap）
gcc --version          # 需要一套可用的工具链来编译新 GCC
make --version         # GNU make
bison --version        # 生成语法分析器（可选但建议）

# CentOS / RHEL 上一次性装齐基础开发工具
sudo yum groupinstall "Development Tools"

3.4 第一步：下载源码与准备依赖

GCC 的所有版本都发布在 GNU 官方 FTP 上：https://ftp.gnu.org/gnu/gcc/（入口页是 gcc.gnu.org 的 Releases 页面）。国内网络访问 ftp.gnu.org 可能较慢，可以改用清华 TUNA 镜像 https://mirrors.tuna.tsinghua.edu.cn/gnu/gcc/，文件内容完全一致。本章素材下载的是 gcc-5.1.0——这是首个完整支持 C++14 的版本，2020 年那会儿用它来编译对 C++14 有要求的 POCO 库正合适。

源码解压后先别急着 configure，GCC 编译自己需要三个数学库：GMP（GNU Multiple Precision Arithmetic Library，任意精度整数/有理数运算库）、MPFR（基于 GMP 的多精度浮点运算库，保证正确舍入）、MPC（基于 GMP 和 MPFR 的复数运算库）。GCC 的前端在编译期做高精度常量运算（比如折叠 constexpr 浮点表达式）时会用到它们。GCC 5.1 对版本的要求是：GMP 4.2+、MPFR 2.4.0+、MPC 0.8.0+——不满足时 configure 会直接报错。

# 从 GNU 官方 FTP 下载并解压（国内可换 TUNA 镜像，见上方提示）
wget https://ftp.gnu.org/gnu/gcc/gcc-5.1.0/gcc-5.1.0.tar.bz2
tar xjf gcc-5.1.0.tar.bz2
cd gcc-5.1.0

最简单的依赖准备方式，是运行源码树里自带的脚本 ./contrib/download_prerequisites——它自动从 ftp://gcc.gnu.org/pub/gcc/infrastructure/ 下载 GCC 官方测试过的依赖版本（在 5.1.0 里是 gmp-4.3.2、mpfr-2.4.2、mpc-0.8.1，以及用于 Graphite 循环优化的 isl-0.14），解压到源码树内并创建 gmp、mpfr、mpc 软链接，顶层 configure 会自动识别它们，无需手动安装到系统。

# 一键下载并安放全部依赖（素材中的真实命令，在源码目录内执行）
./contrib/download_prerequisites

# 脚本会创建如下软链接，configure 阶段自动识别：
# gmp -> gmp-4.3.2   mpfr -> mpfr-2.4.2   mpc -> mpc-0.8.1

如果不想用脚本，也可以手动下载更新的依赖版本、逐个编译安装（素材里就是这么做的，用的是当时较新的 gmp-6.1.0 / mpfr-3.1.4 / mpc-1.0.3，默认安装到 /usr/local）：

# 备选方案：手动下载依赖（官方基础设施目录）
wget ftp://gcc.gnu.org/pub/gcc/infrastructure/gmp-6.1.0.tar.bz2
wget ftp://gcc.gnu.org/pub/gcc/infrastructure/mpfr-3.1.4.tar.bz2
wget ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-1.0.3.tar.gz

# 依次解压、configure、编译、安装（先 gmp，再 mpfr，最后 mpc）
tar xjf gmp-6.1.0.tar.bz2
cd gmp-6.1.0
./configure
make && sudo make install
cd ..

# mpfr、mpc 同样操作，顺序不能乱：mpc 依赖 gmp 和 mpfr

3.5 第二步：configure：探测环境、生成构建配置

configure 是一个由 autoconf 工具生成的可执行脚本（几乎所有 GNU 软件的源码树里都有），它的职责是探测当前系统的环境：有没有可用的编译器、各依赖库装在哪、头文件在不在、CPU 是什么架构，然后把结果写进生成的 Makefile 和 config.h。换句话说，configure 负责回答"这台机器上怎么编译"，make 负责回答"按这个方案编译"。同一个源码包，在千奇百怪的 Linux 环境里都能编译成功，靠的就是这一层探测。

GCC 的 configure 参数很多，日常够用的就这几个：--prefix 指定安装目录（默认 /usr/local，多版本共存时改成 /opt/gcc-5.1.0 之类的独立目录）；--enable-languages=c,c++ 只编译 C 和 C++ 两个前端（默认会编全部语言，白白多花几十分钟）；--enable-checking=release 控制编译器内部一致性检查的强度（release 是性能与安全之间的折中，默认是 yes）；--disable-multilib 禁止生成 32 位变体——64 位系统上如果没装 32 位库，多库支持会导致链接阶段报错，直接关掉最省心。

# 素材中的真实配置命令（在 gcc-5.1.0 源码目录内执行）
./configure --enable-checking=release --enable-languages=c,c++ --disable-multilib

# 多版本共存时，用 --prefix 把新 GCC 装到独立目录
./configure --prefix=/opt/gcc-5.1.0 \
    --enable-languages=c,c++ \
    --enable-checking=release \
    --disable-multilib

# 依赖装到非标准位置时，用 --with-* 指明路径（按需）
# ./configure --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local

还有一个推荐做法：out-of-tree 构建——在源码目录外单独建一个 build 目录，从那里调用源码树里的 configure。这样编译产生的海量中间文件全部落在 build 目录里，源码目录始终保持干净，想重来就删掉 build 目录，源码毫发无损。

# 推荐：源码目录外构建（用 ../configure 引用源码树）
mkdir build
cd build
../configure --enable-checking=release --enable-languages=c,c++ --disable-multilib

3.6 第三步：编译、安装与验证

configure 顺利通过后，真正的重头戏来了。make 默认是单线程编译，GCC 这种体量的项目会慢到怀疑人生，所以一定要并行：make -j$(nproc)（nproc 输出 CPU 核数，让编译任务铺满所有核）。默认配置下 make 会执行三阶段自举：第一阶段用系统老编译器编译出新 GCC；第二阶段用这个新 GCC 重新编译自己；第三阶段再编译一次并与第二阶段的结果比对，确保编译器"自我一致"。整个过程在八核机器上通常要 30 分钟到 1 小时以上，期间风扇狂转是正常现象。

编译完成后 make install 把产物安装到 --prefix 指定的目录（默认 /usr/local）：可执行文件进 /usr/local/bin（gcc、g++、gfortran 等），库文件进 /usr/local/lib64（libstdc++.so.6 就在这里），C++ 标准库头文件进 /usr/local/include/c++/5.1.0。安装完成后用 gcc -v 或 gcc --version 验证版本——素材里的真实输出是 gcc version 5.1.0 (GCC)。

# 并行编译：-j 后面跟并行任务数，$(nproc) 自动取 CPU 核数
make -j$(nproc)

# 编译通过后安装（默认装到 /usr/local，需 root 权限）
sudo make install

# 验证版本（素材中的真实输出）
gcc -v
# gcc version 5.1.0 (GCC)
gcc --version
# gcc (GCC) 5.1.0
g++ --version

# 小实验：编译一个需要 C++14 的程序，确认新编译器真的能用
g++ -std=c++14 hello.cpp -o hello && ./hello

验证通过，但还有最后一道坎：新编译器的库，系统找不找得到。新 GCC 的 libstdc++ 装在 /usr/local/lib64，而系统里其他程序（以及后续编译出的程序）默认去 /usr/lib64 找库——版本对不上时，运行程序会报 libstdc++.so.6: version 'GLIBCXX_3.4.21' not found。素材里的处理办法是把新库复制到系统库目录（需要 root）：

# 素材中的真实处理：把新 libstdc++ 复制到系统库目录
cp -vf /usr/local/lib64/libstdc++.* /usr/lib64/

# 不想动系统目录的话，用环境变量指路（仅对当前 shell 生效）
export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH

3.7 常见坑与多版本共存

把源码安装整条链路跑通之后，还有一批高频问题值得提前打预防针。下面这张表汇总了最常见的报错、原因和解决方向——建议收藏，遇到问题先对号入座，再动手。

报错现象	原因	解决
configure: error: gmp.h not found / Building GCC requires GMP…	GMP/MPFR/MPC 依赖未就绪	跑 ./contrib/download_prerequisites 或装 dev 包
error: No usable m4 in $PATH or /usr/5bin	系统缺 m4 宏处理工具	yum install m4 / apt install m4
libstdc++.so.6: version 'GLIBCXX_3.4.21' not found	运行时用了系统旧版 libstdc++	复制新库到 /usr/lib64 或设置 LD_LIBRARY_PATH
/usr/bin/ld: cannot find -lstdc++	链接器没找到新标准库	确认安装路径，必要时加 -L/usr/local/lib64
make 中途被 kill / internal compiler error	内存或磁盘不足	降低 -j 并行度，清理磁盘空间

第二个高频主题是多版本共存。生产环境里常见的诉求是"系统默认 GCC 不动，新 GCC 供特定项目用"。做法很简单：新版本用 --prefix=/opt/gcc-5.1.0 装到独立目录，然后通过 PATH 环境变量控制"哪个 gcc 生效"。PATH 是 shell 查找命令时依次扫描的目录列表，排在前面的目录优先——把新 GCC 的 bin 目录放在 PATH 最前面，gcc 就指向新版本；去掉它，又回到系统版本。改完 PATH 记得 hash -r 清除 shell 的命令路径缓存，并用 which gcc 确认当前生效的是谁。

# 把新 GCC 放到 PATH 最前面（当前 shell 立即生效）
export PATH=/opt/gcc-5.1.0/bin:$PATH

# 确认当前生效的 gcc 到底是哪个（输出 /opt/gcc-5.1.0/bin/gcc）
which gcc

# 写进 ~/.bashrc 永久生效，然后刷新；hash -r 清除旧路径缓存
echo 'export PATH=/opt/gcc-5.1.0/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
hash -r

# 排查"新 gcc 编译的程序跑不起来"的完整流程
# 1. 看可执行文件依赖了哪些动态库
ldd ./app | grep stdc++
#   libstdc++.so.6 => /usr/lib64/libstdc++.so.6  ← 找到旧库了

# 2. 确认新库的版本符号是否满足要求
strings /usr/local/lib64/libstdc++.so.6 | grep GLIBCXX_3.4.21

# 3. 让运行时找到新库（二选一）：复制到系统目录，或设 LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH

最后一个提醒关于 ABI 兼容性（ABI 是 Application Binary Interface，说人话就是"编译好的二进制之间互相调用的约定"）。GCC 5 起 libstdc++ 默认启用新的 C++11 ABI（可用宏 _GLIBCXX_USE_CXX11_ABI 查看，默认值为 1），这是 GCC 5 发布说明里明确标注的重大变更：用新编译器编译的库和用老编译器编译的库，std::string 等类型的内部布局不同，混链可能出问题。如果你的项目要链接一批用老 ABI 编译的第三方库，可以给新编译加 -D_GLIBCXX_USE_CXX11_ABI=0 切回旧 ABI——但整个项目的所有编译单元必须保持一致。

# 查看当前编译器默认的 ABI 模式（1 = 新 C++11 ABI，0 = 旧 ABI）
g++ -dM -E -x c++ /dev/null | grep _GLIBCXX_USE_CXX11_ABI
# #define _GLIBCXX_USE_CXX11_ABI 1

# 需要兼容旧 ABI 库时，统一加这个宏再编译
g++ -std=c++14 -D_GLIBCXX_USE_CXX11_ABI=0 app.cpp -o app