Linux 编译：从一行 C 到可验证的构建产物

在终端里敲下 gcc main.c -o app，几秒后多出一个可执行文件，看起来像是“一条命令把源码变成程序”。这个说法方便入门，却藏住了真正决定成败的环节：头文件怎样展开，多个翻译单元怎样分别生成对象，未定义符号由谁补齐，共享库在运行时去哪里找，构建系统为什么只重编一部分，以及安装为什么不该直接改动系统目录。

我们会把这条链拆开，再重新接起来。目标不是背参数，而是看到任何产物或错误时，都能回答三个问题：它处在哪个阶段？上一阶段留下了什么证据？下一步应该用什么工具验证？

先界定“成功”：编译只是交付链的一段

从源码到运行，中间至少有六个可独立失败的关口

以 C 项目为例，可以把过程画成这条证据链：

源文件与头文件
  → 预处理后的翻译单元
  → 汇编文本
  → 可重定位对象
  → 可执行文件或共享对象
  → 动态加载后的进程
  → 测试通过的行为
  → 经过核对的安装产物

每个箭头都回答不同问题。预处理器关心宏和头文件；编译器关心语法、类型和目标指令；汇编器把汇编文本编码成机器码；链接器解析符号与重定位；加载器把可执行文件和共享库映射进进程；测试才检查输出、状态和副作用；安装还要核对路径、权限、配置与可回滚性。

所以，“gcc 没报错”最多说明它负责的阶段完成了。它不能证明程序给出了正确答案，也不能证明目标系统有兼容库，更不能证明把文件复制到某个前缀后服务就安全可用。

编译成功、测试通过与可部署是三份不同的证明

我们可以用一个刻意写错的程序看清边界：

#include <stdio.h>
 
int main(void) {
    puts("result=5");
    return 0;
}

它能以 -Wall -Wextra -Wpedantic 编译，并以状态 0 退出。但如果契约要求 result=4，验收测试仍然失败。进一步说，即使测试通过，把它部署到另一个环境时仍可能遇到 CPU 架构、glibc 版本、共享库 ABI、文件权限或配置路径差异。

一条可靠的流水线通常分别保存这些证据：

• 构建证据：完整命令、编译器版本、目标架构、警告和产物哈希。
• 测试证据：测试集合、输入、期望、实际结果、退出状态与覆盖边界。
• 安装证据：暂存目录清单、目标前缀、权限、动态依赖和卸载/回滚方法。
• 运行证据：部署环境中的冒烟测试、日志、健康状态和资源限制。

gcc 是驱动程序：把流水线逐段停下来

-E 只做预处理：宏、条件与头文件在这里展开

gcc 是一个编译器驱动。它根据文件后缀和选项调用预处理器、编译器主体、汇编器与链接器。最早的停止点是 -E：

gcc -std=c17 -DAPP_NAME='"welearn"' -E hello.c -o hello.i

hello.i 仍是 C 文本，只是 #include 的内容已被纳入，宏已经替换，条件编译不成立的分支被移除。文件通常很大，因为一个很短的源文件可能包含大量系统声明。我们关心的不是通读全部内容，而是确认某个宏究竟展开成什么、某个声明是否真的进入翻译单元。

-I目录 增加头文件搜索路径，-DNAME=value 定义宏。它们本质上是预处理参数，放进 Makefile 时通常归入 CPPFLAGS。#include "calc.h" 往往先查当前源文件相关目录，再走用户和系统搜索路径；#include <calc.h> 通常用于配置好的包含目录。具体顺序受编译器和选项影响，可用 gcc -E -v 观察，不靠猜。

-S 与 -c 分别停在汇编文本和对象文件

接下来可以逐段生成产物：

gcc -std=c17 -Wall -Wextra -Wpedantic -S hello.c -o hello.s
gcc -std=c17 -Wall -Wextra -Wpedantic -c hello.c -o hello.o

-S 在编译器生成目标架构汇编后停止，输出 .s 文本。它适合观察优化前后指令变化、函数标签和调用形态，但不能仅凭几行汇编判断程序性能。

-c 的意思是“编译或汇编，但不链接”。对于 .c 输入，驱动会完成预处理、编译和汇编，得到 .o 可重定位对象。对象里已经有机器码和数据，却可能仍保留未定义符号与重定位项，因此通常不能直接当程序启动。

最后一条 gcc 命令通常负责链接，内核与加载器随后接手

把对象组合成程序时，仍建议调用编译器驱动：

gcc main.o calc.o -o app

直接调用 ld 要自己处理启动对象、动态加载器路径、默认库和目标选项，普通项目没有必要重复驱动已经掌握的规则。gcc -v main.o calc.o -o app 可以显示驱动实际调用了哪些子程序和参数；传给链接器的选项用 -Wl,选项,参数，例如 -Wl,-Map,app.map。

链接完成后，执行文件还没有“运行”。内核读取 ELF 入口和解释器信息，动态加载器映射所需共享对象、执行重定位和初始化，最后才把控制权交给程序入口。静态链接程序的路径不同，但同样要满足可执行格式、架构与内核接口条件。

源文件、头文件与翻译单元：先分清声明和定义

头文件写契约，源文件放实现

多文件项目常用头文件公布接口：

/* include/calc.h */
#ifndef CALC_H
#define CALC_H
 
int calc_add(int left, int right);
 
#endif

这行函数原型是声明：它告诉编译器名称、参数和返回类型。实现通常放在一个源文件里：

/* src/calc.c */
#include "calc.h"
 
int calc_add(int left, int right) {
    return left + right;
}

这里才是能产生外部符号的定义。头文件保护宏避免同一个翻译单元重复纳入声明，但它不能阻止多个源文件各自产生同名外部定义。把普通函数实现直接写进公共头文件，容易在链接阶段得到 multiple definition；若确实需要头文件实现，必须理解 static inline、语言标准和可见性语义，而不是随手加关键字消音。

每个 .c 经预处理形成一个翻译单元，API 与 ABI 分属两层

编译器不是把目录里的所有 .c 一起理解。通常每个源文件连同展开后的头文件独立形成一个翻译单元，再生成自己的对象。main.c 能根据声明检查 calc_add 调用类型，却不知道另一个对象里是否真的有兼容实现；这个问题留到链接阶段。

API 是源码层的使用契约，例如函数名、参数含义、返回值和头文件。ABI 是二进制层约定，例如调用约定、数据类型大小与对齐、符号命名、结构体布局、异常和版本化规则。API 不变不代表 ABI 一定兼容：更换编译选项、架构或结构体布局，都可能让旧对象不能安全调用新库。

一个实用原则是：跨模块边界传递的数据结构要有明确版本与所有权；升级共享库时检查 SONAME 和发行说明；不要把“头文件还能编译”当成“已有二进制无需重建”。

对象文件不是黑盒：用符号与重定位解释链接

nm 看谁定义、谁欠账，readelf 看 ELF 结构和重定位

假设 main.o 调用 calc_add 和 printf，而 calc.o 实现 calc_add：

nm -u build/main.o
nm --defined-only build/calc.o
readelf -r build/main.o

可能看到：

                 U calc_add
                 U printf
0000000000000000 T calc_add

U 表示该对象使用符号但没有定义；T 表示定义位于代码段。U 并不等于对象损坏，它是一张待链接器结清的“欠条”。readelf -r 展示重定位项：某条调用指令或数据引用在对象生成时还不知道最终地址，链接器把选定定义的地址写入相应位置，或为动态加载保留运行时重定位。

readelf 直接理解 ELF 结构，适合看文件头、节、程序头、动态段、符号和重定位；objdump 还能借助 BFD 显示对象信息与反汇编：

readelf -h -S -s -r build/main.o
objdump -d build/calc.o

未定义引用、重复定义与静态库顺序是三类不同问题

undefined reference to calc_add 说明最终链接仍缺定义，常见原因有：对象漏写、-l 名称错误、-L 目录不对、库版本未导出符号，或 C/C++ 名称修饰和 ABI 不匹配。新增一个函数声明不能修复它，因为声明不产生实现。

multiple definition of calc_add 则说明强定义多于一个。应找到每个定义的来源，确认实现是否误放进头文件，或是否把两个互斥实现一起链接。

静态归档还有读入顺序。传统链接器从左向右处理输入，只有当前未解决符号需要某个归档成员时才把它抽出。因此通常写成：

gcc build/main.o -Llib -lcalc -o bin/app

若把 -lcalc 放在提出需求的 main.o 之前，可能出现看似“库明明有符号”却未被抽取的情况。循环库依赖应优先从模块结构解决；链接组是工具，不是掩盖设计问题的默认选项。

静态库与共享库：链接时找到还不够

静态归档是对象集合，链接器按需复制成员

静态库通常用 ar 生成：

ar rcs lib/libcalc.a build/calc.o
ar t lib/libcalc.a
gcc build/main.o -Llib -lcalc -o bin/app-static

-lcalc 会让链接器寻找 libcalc.so 或 libcalc.a，具体选择受平台和选项影响。使用静态归档时，链接器把满足符号需求的对象成员纳入最终程序。运行时不再需要这份 .a，但已复制进去的代码不会因为库文件后来修补而自动更新；安全修复往往需要重新链接和重新发布所有使用者。

静态链接也不是“完全没有运行环境依赖”的同义词。程序仍依赖内核 ABI、配置、名称解析、证书、时区和其他数据文件；glibc 某些功能在静态场景还可能有额外限制。是否静态化要根据交付与更新模型决定。

共享库用 SONAME 表达 ABI 身份，文件名链接组成版本关系

共享库需要位置无关代码，常见构建方式是：

gcc -fPIC -Iinclude -c src/calc.c -o build/calc.pic.o
gcc -shared -Wl,-soname,libcalc.so.1 \
  -o lib/libcalc.so.1.0 build/calc.pic.o
ln -s libcalc.so.1.0 lib/libcalc.so.1
ln -s libcalc.so.1 lib/libcalc.so

libcalc.so 是链接时开发名称，libcalc.so.1 是运行时 ABI 身份，libcalc.so.1.0 是具体实现。链接器看到共享对象的 DT_SONAME 后，把 libcalc.so.1 写入可执行文件的 DT_NEEDED。兼容更新可以让 SONAME 链接指向新实现；破坏 ABI 的更新应改变主 SONAME，而不是让旧程序悄悄加载不兼容实现。

-L 只管链接搜索；RUNPATH 与加载器策略才管启动

下面的命令可能链接成功：

gcc build/main.o -Llib -lcalc -o bin/app-shared

但执行时仍可能得到：

error while loading shared libraries: libcalc.so.1: cannot open shared object file

原因是 -Llib 只告诉链接器去哪里找库，不自动承诺运行时从相同相对目录加载。常见解决方案按交付模型选择：

• 把库安装到受管理的系统目录，并由包管理器维护缓存与版本关系。
• 对“程序旁自带私有库”的布局，写入经过审查的相对 RUNPATH，例如链接参数 -Wl,-rpath,'$ORIGIN/../lib'。单引号防止 Shell 提前展开 $ORIGIN。
• 仅在受控诊断中临时设置 LD_LIBRARY_PATH，并记录其值；不要把可写目录放进全局搜索路径，也不要依赖它绕过正式安装。

加载顺序受 DT_RPATH、LD_LIBRARY_PATH、DT_RUNPATH、/etc/ld.so.cache、默认目录和安全执行模式共同影响，且 RUNPATH 对间接依赖的传播规则与旧 RPATH 不同。排障时读取实际动态段，而不是背一条脱离目标环境的绝对顺序。

编译参数是质量控制，不是越多越好

先固定语言标准和警告基线，再决定哪些警告阻断构建

一个朴素的开发基线可以是：

gcc -std=c17 -Wall -Wextra -Wpedantic -c src/main.c -o build/main.o

-std=c17 选择语言版本；-Wall 和 -Wextra 启用两组常用诊断，但并不等于“所有警告”；-Wpedantic 按所选 ISO 标准提示扩展。警告不一定都是缺陷，却是应该阅读和分类的证据。盲目加 -w 会隐藏未来的兼容问题。

-Werror 把警告提升为错误，适合在版本固定、基线清洁的持续集成中使用。对跨多个编译器版本的第三方源码，新增诊断可能让没有行为错误的旧代码突然无法构建，因此更稳妥的做法是：维护明确的工具链版本、修复警告，必要时仅对已评估的某一项使用 -Wno-error=名称，而不是关闭全部诊断。

-g、优化级别和 Sanitizer 服务不同阶段

-g 让编译器生成调试信息，便于调试器和崩溃分析定位到函数与源码行。它可以与优化一起使用，但优化会折叠、重排或删除代码，使单步调试和变量观察不再完全对应源码。常见组合包括：

Sanitizer 是插桩构建，不是发布构建的天然替代品。它可能改变时间、内存布局和性能；不同 Sanitizer 也不一定能组合。更关键的是，编译器优化和未定义行为会改变被保留的代码，插桩只能检查最终二进制真正执行的访问。一次无报告运行只证明这次路径没有触发已覆盖的问题。

Make 管的是依赖图，不是一串顺序命令

目标、前置文件、配方和时间戳共同决定是否重建

一条 Make 规则的骨架是：

目标: 前置文件
	生成目标的配方

传统 Makefile 中，配方行开头是 Tab。把它换成普通空格，常见结果是 missing separator，而且错误发生在 Make 解析阶段，编译器根本没有启动。

Make 通常比较目标和前置文件的修改时间：目标不存在，或任一普通前置文件比目标新，就执行配方。若 main.o 更新，依赖它的 app 也会更新；这是一条沿图向上的连锁，而不是 Make 记住了某个“步骤编号”。时间戳被错误回拨、网络文件系统时钟不一致或配方没有真正刷新目标，都可能破坏判断。

变量、模式规则与自动依赖让图保持真实

一个可维护的多文件示例：

CC ?= gcc
CPPFLAGS += -Iinclude
CFLAGS += -std=c17 -Wall -Wextra -Wpedantic -MMD -MP
OBJS := build/main.o build/calc.o
DEPS := $(OBJS:.o=.d)
 
.PHONY: all check clean
all: bin/app
 
bin/app: $(OBJS) | bin
	$(CC) $(LDFLAGS) $^ $(LDLIBS) -o $@
 
build/%.o: src/%.c | build
	$(CC)

$@ 是当前目标，$< 是第一个普通前置文件，$^ 是去重后的普通前置文件集合。%.o: %.c 是模式规则。竖线后的 bin 是 order-only prerequisite：目录必须先存在，但目录时间变化不应迫使程序重新链接。

-MMD -MP 让编译器为用户头文件生成 .d 依赖。否则 calc.h 改了，Make 只看到 .c → .o，可能错误地复用旧对象。自动生成依赖仍要随对象一起清理并纳入构建目录。

.PHONY 声明 clean、check 不是同名文件。若目录里恰好出现名为 clean 的文件而规则未声明 phony，Make 可能认为目标已经存在并跳过配方。

并行构建会揭穿隐含依赖，clean、check、install 不能混为一谈

make -j2 可以同时构建互不依赖的对象，等它们完成后再链接。若配方靠“另一个规则碰巧先运行”却没有写前置关系，串行时可能偶然通过，并行时就出现竞态。正确修复是补全依赖和输出关系，不是永久关闭并行。

常见目标承担不同职责：

• all 构建默认产物。
• check 或 test 运行验证；构建成功不会自动代表它执行过。
• clean 删除对象和生成物；它应该只清理项目构建目录，避免变量为空时扩大删除范围。
• install 把已构建文件复制到前缀。执行前先用 make -n install 预览，并优先写入 DESTDIR 暂存区。

不要把 clean 设成真实文件目标的普通前置文件，否则每次构建都可能先删成果，增量和并行都失去意义。也不要同时发起 make clean 与 make -j，除非项目明确设计了这种并发关系。

pkg-config：让依赖库报告编译与链接参数

--cflags 和 --libs 分别服务编译与链接

依赖安装在多架构或自定义前缀时，手写 -I、-L 和 -l 容易遗漏。库可以提供 .pc 元数据：

prefix=/opt/calc
includedir=${prefix}/include
libdir=${prefix}/lib
 
Name: calc
Description: arithmetic example
Version: 1.0.0
Cflags: -I${includedir}
Libs: -L${libdir} -lcalc

使用时先检查模块与版本：

pkg-config --modversion calc
pkg-config --cflags calc
pkg-config --libs calc
gcc src/main.c $(pkg-config --cflags --libs calc) -o bin/app

生产构建更常在 Make、Autoconf、CMake 或 Meson 中调用 pkg-config 并正确处理失败，而不是把命令替换散落在脚本里。PKG_CONFIG_PATH 可为受控前缀增加 .pc 搜索目录；它影响找到哪份元数据，必须像库搜索路径一样记录和审查。

公共依赖与私有依赖会改变下游的直接链接关系

.pc 中常见字段包括 Requires、Requires.private、Libs 与 Libs.private。若库的公共头文件暴露另一个模块的类型，下游编译就需要相应头文件；若依赖只在内部实现中使用，通常不应强迫每个动态链接使用者都直接链接它。私有字段会在 pkg-config --static 等场景补充静态链接所需依赖，减少不必要的过度链接。

元数据不是天然可信。.pc 文件可以注入任意编译或链接选项；自定义 PKG_CONFIG_PATH 指向用户可写、来源不明的目录时，构建命令就可能被改变。排障时打印最终命令，并确认它读到的模块版本和目录。

构建第三方源码前，先过来源与依赖门

哈希检查完整性，签名把内容绑定到受信任身份

源码归档至少要记录项目、版本、下载位置、发布日期和预期哈希。sha256sum -c 可以确认收到的字节与清单一致：

sha256sum -c SHA256SUMS

但如果归档和哈希清单来自同一个被替换的页面，二者可以一起被篡改。签名增加身份验证：用已经受信任的 GnuPG 安装验证分离签名，并通过独立渠道核对发布密钥完整指纹。Good signature 只说明签名与某把密钥匹配；还要确认这把密钥确实属于预期发布者、未撤销且用途正确。

不要使用刚下载、尚未验证的工具来验证它自己。也不要因为来源公开就假定安全：构建脚本能执行任意命令，依赖解析还可能引入另一个来源。

解包只是读取数据，运行 configure 已经是在执行代码

可以先在隔离目录中只列清单，再解包：

tar -tf package.tar.xz | sed -n '1,40p'
mkdir -p /tmp/build-review
tar -xf package.tar.xz -C /tmp/build-review

检查绝对路径、../ 穿越、符号链接、文件数量和异常权限。接着阅读 README、INSTALL、变更记录和构建定义，确认需要的编译器、生成器、开发头文件、可选功能与测试命令。./configure --help、CMake 配置和 Meson 配置都可能加载项目逻辑，因此应在来源核验之后、非特权且网络和文件访问受限的环境里执行。

依赖要区分运行包与开发包：运行包可能只有 libfoo.so.1，编译还需要头文件、libfoo.so 链接名和 .pc 文件。版本约束、功能开关、CPU 架构和交叉编译工具链也要记录。不要看到 header.h: No such file 就从陌生网站单独下载一个头文件塞进 /usr/include，那会让接口和实现失去版本关系。

从配置到暂存安装：每一步都可预览、可检查

Autoconf 项目用独立构建目录保留干净源码树

典型流程可以这样组织：

mkdir -p build
cd build
../configure --prefix=/opt/welearn
make -j2
make check

configure 会探测编译器、头文件、函数、库与目标特征，再从模板生成 Makefile 和配置头。它成功只说明这些探测按当前参数通过，不代表后续构建或测试一定成功。失败时应从 config.log 找最早失败的 conftest 命令和编译器原始消息；顶层的 C compiler cannot create executables 只是汇总。

把包含目录放进 CPPFLAGS，普通编译选项放 CFLAGS，链接器搜索和选项放 LDFLAGS，库名按项目规则放 LIBS 或 LDLIBS。一处漏掉短横线的 CPPFLAGS=Iinclude 就可能让探测把参数当成文件名。参数变化后使用新的构建目录，或按项目说明清理缓存，避免旧结论混入新配置。

prefix 决定最终布局，DESTDIR 只在暂存时加一层根

--prefix=/opt/welearn 表示最终希望文件位于 /opt/welearn/bin、/opt/welearn/lib 等位置。DESTDIR 则在安装阶段把一层暂存根加在这些最终路径之前：

make -n install
rm -rf /tmp/welearn-stage
make DESTDIR=/tmp/welearn-stage install
find /tmp/welearn-stage -type f -o -type l

如果最终路径是 /opt/welearn/bin/app，暂存结果应是 /tmp/welearn-stage/opt/welearn/bin/app。程序内部记录的前缀仍是 /opt/welearn，不是暂存目录。这样可以在不改系统目录的情况下检查文件清单、权限、所有权意图、动态依赖和包内容。

不把 install 目标直接提权执行。它可能覆盖发行版文件、运行脚本或把路径写错；先 dry-run，再 DESTDIR，最后交给包管理器或经过审核的部署步骤。make install-strip 也不是默认选择，调试信息应按发布策略分离并保留可追溯符号。

CMake 与 Meson改变前端，不改变证据链

现代项目可能提供 CMakeLists.txt 或 meson.build。它们通常鼓励源外构建：

#CMake
cmake -S . -B build -DCMAKE_INSTALL_PREFIX=/opt/welearn
cmake --build build --parallel 2
ctest --test-dir build --output-on-failure
DESTDIR=/tmp/welearn-stage cmake --install build
 
#Meson
meson setup build --prefix=/opt/welearn
meson compile -C build
meson test -C build
DESTDIR=/tmp/welearn-stage meson install

它们能生成 Ninja、Makefile 或其他后端，并提供目标级依赖、测试和安装描述，但不会替你完成来源验证、ABI 判断或部署验收。先识别项目声明的构建系统，不要同时手改生成文件和源构建定义；配置参数、生成器版本与工具链文件也应进入可复现记录。

排障与实操：沿最早缺失的证据向下走

编译、链接、加载与 Make 错误要先归类

看到长日志时，不要从最后一行 Error 2 开始猜。递归 Make 会把底层失败逐层向上传播；真正原因通常在第一条带文件、行号、符号或工具名的具体消息附近。

readelf、nm、objdump 和 ldd 各有安全边界

对自己刚构建、来源明确的程序，可以组合这些命令：

file bin/app
nm -u build/main.o
readelf -h -l -S -s -r build/main.o
readelf -d bin/app | grep -E 'NEEDED|RPATH|RUNPATH'
objdump -p bin/app | grep NEEDED
objdump -d build/calc.o
ldd bin/app

file 给出格式、架构和链接类型；nm 适合符号概要；readelf 直接读 ELF；objdump 查看对象信息和反汇编；ldd 展示加载解析结果。但不要对不可信可执行文件运行 ldd。某些实现或特殊 ELF 解释器可能导致目标代码执行。未知文件优先用 readelf -d 或 objdump -p 读取 NEEDED 名称，并在隔离分析环境继续处理。

真正的实验在一次性 Debian 容器中自建了 hello.c、两个翻译单元、头文件、静态库、共享库和 Makefile。观察到的关键结果是：

• -E、-S、-c 分别产生 C 文本、汇编文本和 AArch64 ELF 可重定位对象；最终程序是动态链接 PIE。
• main.o 对 calc_add 和 printf 显示 U；calc.o 对 calc_add 显示 T；重定位表保留相应调用位置。
• 无运行搜索路径的共享程序以状态 127 失败；临时受控搜索和 $ORIGIN/../lib RUNPATH 都能让自建程序输出 sum=42。
• 改动公共头文件后，带 -MMD -MP 的 Make 计划重编两个对象再链接；第二次无改动构建不执行命令，-j2 并行对象后再链接。
• 警告提升为错误时，未使用参数让构建以非零状态结束；-O0 的 ASan 受控越界以状态 134 报告 heap-buffer-overflow。
• 自建 Autoconf 项目以 /opt/welearn 为前缀，实际文件只写入 /tmp/welearn-ch23/stage/opt/welearn/bin；哈希篡改、错误行为测试均被非零状态捕获。

实验结束时，make clean 删除生成目录，暂存区和全部源码由退出陷阱删除，--rm 容器消失。这里的命令输出不是为了证明某个固定架构才正确，而是示范如何保存“成功分支”和“预期失败分支”的状态、消息与产物证据。

一份可以直接执行的构建验收清单

把整个流程压缩成一张清单，顺序比命令数量更重要：

1. 确认来源：记录项目、版本和下载位置；核对哈希，能用签名时再独立确认密钥指纹。
2. 检查归档：先列路径，再解包到隔离、非特权目录；阅读构建说明和入口脚本。
3. 记录环境：保存架构、编译器、链接器、构建系统版本，以及 CPPFLAGS、CFLAGS、LDFLAGS、pkg-config 路径和功能开关。
4. 源外配置：使用独立构建目录；配置失败就读原始探测日志，不反复叠加随机参数。
5. 分段构建：遇错先定位预处理、编译、汇编或链接阶段；用 nm、readelf、objdump 找证据。
6. 运行测试：构建目标与 check/test 目标分开记录；保存失败输入、期望、实际和退出状态。
7. 检查加载：读取 NEEDED、SONAME 与 RUNPATH；只对可信自建程序使用 ldd，并验证目标环境的实际启动。
8. 暂存安装：先 dry-run，再用 DESTDIR；审查路径、权限、符号链接、调试信息和动态依赖，不直接让安装脚本改系统目录。
9. 形成可交付物：优先打包，让安装、升级和卸载有清单；记录产物哈希和工具链信息。
10. 清理与复验：删除构建/暂存目录，确认隔离环境消失，再从干净输入重复关键步骤。

这套顺序的核心只有一句话：不要用后一个阶段的“看起来成功”替代前一个阶段的证据，也不要用编译器的退出状态替代测试和部署验收。