C/C++编译链接全流程解析：从源代码到可执行文件

1. 从文本到机器指令：编译与链接到底在干什么

很多人写了好几年代码，对“编译”这个词的理解还停留在“点一下运行按钮，代码就跑起来了”。一旦遇到undefined reference to xxx或者multiple definition of xxx这种报错，就彻底懵了，只能靠搜索引擎碰运气。我刚开始写C/C++的时候也是这样，直到有一次排查一个符号冲突问题，被逼着把整个编译链接流程啃了一遍，才发现这里面藏着的东西远比想象中有意思。

这篇文章想聊的，就是一段源代码从你敲下回车到变成一个真正能跑的可执行文件，中间到底经历了什么。核心关键词就两个：编译和链接。编译负责把你能看懂的C/C++代码翻译成机器能看懂的二进制指令，链接负责把这些零散的指令拼装成一个完整的、操作系统能加载运行的程序。搞懂这套流程，你就能明白为什么头文件要那样写、为什么静态库和动态库行为不一样、为什么有时候改了代码却没生效。适合所有写C/C++的开发者，不管你是刚入门的新手，还是写了几年但一直没深究底层的老手，都能从里面挖到对自己有用的东西。

我打算按真实的处理顺序来讲：先看编译器怎么一步步把.c文件变成.o文件，再看链接器怎么把一堆.o文件和库文件拼成最终的可执行文件，最后聊聊实际开发中那些和编译链接相关的坑。整个过程我会尽量用生活化的类比来解释，同时把关键的命令和参数都列出来，方便你直接上手验证。

2. 编译阶段：源代码是怎么变成汇编的

2.1 预处理：把代码“膨胀”成真正的编译单元

编译器拿到一个.c文件后，做的第一件事不是翻译，而是预处理。你可以把预处理理解成“文本替换和拼接”——把#include的头文件内容原封不动地插进来，把#define的宏展开，把#ifdef的条件编译分支裁掉。做完这一步，你写的那个几十行的.c文件可能会膨胀成几千行甚至几万行的“编译单元”。

为什么要有这一步？因为编译器本身不想处理头文件查找、宏展开这些琐事，它希望拿到手的是一份“干净”的、没有预处理指令的纯代码。这就像做菜，预处理相当于把所有食材洗好切好摆在你面前，真正炒菜的厨师（编译器）只管下锅。

你可以用gcc -E来单独执行预处理，看看结果：

gcc -E main.c -o main.i

打开main.i你会发现，#include <stdio.h>那一行不见了，取而代之的是几百行stdio.h的内容。#define MAX 100也不见了，代码里所有MAX都被替换成了100。这就是预处理干的事。

这里有个常见的坑：宏展开是纯文本替换，不涉及任何类型检查。比如你写#define SQUARE(x) x*x，然后调用SQUARE(1+2)，展开后变成1+2*1+2，结果是5而不是9。这种问题在预处理阶段不会报任何错，只有到了运行时你才会发现结果不对。所以用宏的时候一定要加括号：#define SQUARE(x) ((x)*(x))。

2.2 编译：从高级语言到汇编代码

预处理完成后，编译器开始真正的工作：把C/C++代码翻译成汇编代码。这一步是整个流程里最复杂的，涉及词法分析、语法分析、语义分析、中间代码生成、优化、目标代码生成等一系列步骤。不过对于日常开发来说，你不需要把每个步骤都搞得清清楚楚，只需要知道编译器在这一步做了哪些关键决策。

首先是语法和语义检查。编译器会检查你的代码是否符合C/C++语法规则，比如括号是否匹配、变量是否声明、类型是否兼容。如果这里报错，就是我们常见的编译错误，比如expected ';' before '}' token这种。

然后是优化。编译器会在这一阶段对你的代码做各种变换，比如把int a = 1 + 2;直接算成int a = 3;，把循环里不变的计算提到循环外面，甚至把整个函数调用内联展开。优化的级别由-O参数控制，从-O0（不优化）到-O3（激进优化），还有-Os（优化体积）和-Ofast（最激进但可能不符合标准）。

我个人的经验是：开发调试阶段用-O0，发布版本用-O2。-O0生成的代码和源代码行号一一对应，用gdb调试的时候不会出现“跳来跳去”的情况。-O2在性能和编译时间之间取得了比较好的平衡，-O3虽然更快但有时候会让代码体积膨胀得厉害，而且极少数情况下可能触发编译器的bug。

你可以用gcc -S来生成汇编代码：

gcc -S main.c -o main.s

打开main.s你会看到类似这样的内容：

main: pushq %rbp movq %rsp, %rbp movl $0, %eax popq %rbp ret

这就是编译器把你的C代码翻译成的汇编代码。虽然看起来很简单，但每一行都对应着CPU的一条指令。

2.3 汇编：把汇编代码翻译成机器指令

汇编器的工作相对简单：把汇编代码逐条翻译成机器指令，生成目标文件（.o文件）。目标文件已经是二进制格式了，里面包含了机器指令、数据、符号表、重定位信息等内容。

为什么叫“目标文件”而不是“可执行文件”？因为它还不能直接运行。目标文件里的地址都是从0开始的，而且它可能引用了外部符号（比如printf），这些符号的地址还没有确定。链接器的工作就是把这些目标文件拼在一起，把地址都填好。

你可以用gcc -c来生成目标文件：

gcc -c main.c -o main.o

然后用objdump或者readelf来查看目标文件的内容：

objdump -d main.o

你会看到反汇编后的机器指令，以及每个函数的符号信息。

这里有一个关键点：目标文件里的符号表记录了哪些符号是定义的，哪些是引用的。比如你的main.o里调用了printf，那么符号表里会有一个printf的未定义引用（UND），链接器看到这个引用后，就会去其他目标文件或库里找printf的定义。如果找不到，就会报undefined reference to 'printf'的错误。

2.4 编译阶段的常见坑与实操心得

编译阶段有几个坑我踩过不止一次，这里列出来供你参考。

第一个坑是头文件包含顺序。C/C++的头文件包含顺序有时候会影响编译结果，因为宏定义和类型定义可能互相依赖。我一般的做法是：先包含标准库头文件，再包含第三方库头文件，最后包含自己的头文件。这样能最大程度避免宏冲突和类型重定义。

第二个坑是内联函数和宏的选择。inline函数有类型检查，调试也方便，但早期C编译器对inline的支持不太好。宏没有类型检查，但展开后代码可能膨胀。我的建议是：能用inline就用inline，实在不行再用宏，而且宏一定要加括号。

第三个坑是编译优化导致的调试困难。前面说过-O2会让代码和源代码行号不对应，但还有一个更隐蔽的问题：编译器可能会把某个变量优化掉，导致你在gdb里print这个变量时显示optimized out。解决办法是在调试时用-O0，或者在gdb里用volatile关键字临时修饰变量。

第四个坑是编译时间过长。大型项目编译一次可能要几十分钟，这时候可以用预编译头文件（PCH）或者分布式编译来加速。预编译头文件的原理是把那些不常变动的头文件（比如标准库头文件）预先编译成二进制格式，后续编译直接加载，省去重复解析的时间。

3. 链接阶段：零散目标文件如何拼成可执行程序

3.1 符号解析：找到每个符号的定义

链接器的第一个任务是符号解析。它扫描所有输入的目标文件和库文件，建立一张全局符号表，记录每个符号的定义和引用。如果某个符号被引用了但没有定义，链接器就报undefined reference错误；如果某个符号被定义了多次，链接器就报multiple definition错误。

这里有一个容易混淆的概念：声明和定义的区别。声明只是告诉编译器“有这么个东西”，定义才是真正分配内存。比如extern int a;是声明，int a = 10;是定义。链接器只关心定义，不关心声明。

符号解析的规则其实不复杂，但有几个细节值得注意：

• 强符号和弱符号：函数和已初始化的全局变量是强符号，未初始化的全局变量是弱符号。链接器允许一个强符号和多个弱符号共存，但多个强符号会报错。这个规则在C++里更复杂，因为C++有函数重载和命名空间。
• C和C++的符号命名差异：C++为了支持函数重载，会对函数名进行名称修饰（name mangling），比如void foo(int)会被修饰成_Z3fooi。这就是为什么C++调用C函数时要用extern "C"，因为C编译器不会做名称修饰，链接器找不到修饰后的符号。
• 静态库的链接顺序：链接器从左到右扫描库文件，遇到未定义符号时才会去后面的库里找。所以如果库A依赖库B，那么命令行里库A要写在库B前面。这个规则经常让人踩坑，报错信息又不够直观。

3.2 重定位：给每个符号分配最终地址

符号解析完成后，链接器知道了每个符号的定义在哪里，接下来就是重定位：给每个符号分配最终的内存地址，然后修改代码中所有引用这些符号的地方。

重定位的过程可以这样理解：目标文件里的代码在调用某个函数时，地址是填的0（或者一个占位符）。链接器确定了这个函数的最终地址后，就把这个地址填回去。这个过程涉及两种重定位：

• 绝对重定位：直接修改指令中的地址字段，适用于绝对寻址。
• 相对重定位：修改指令中的偏移量，适用于相对寻址（比如call指令）。

现代操作系统普遍使用虚拟内存和地址空间布局随机化（ASLR），所以可执行文件里的地址通常是相对地址，程序加载时由操作系统加上基址。这就是为什么可执行文件在不同机器上运行时地址可能不一样。

你可以用readelf -r来查看目标文件里的重定位信息：

readelf -r main.o

输出会列出每个需要重定位的符号、偏移量和重定位类型。

3.3 静态链接与动态链接：两种截然不同的策略

链接方式分为静态链接和动态链接，这是两个完全不同的策略，各有优劣。

静态链接是把所有依赖的库代码直接复制到可执行文件里。优点是部署方便，可执行文件不依赖外部库，拷到任何同架构的机器上都能跑。缺点是文件体积大，而且如果库有安全漏洞，必须重新编译整个程序才能修复。

动态链接是只在可执行文件里记录依赖的库名和符号，程序运行时才加载库。优点是文件体积小，多个程序可以共享同一个库，库更新后所有程序都受益。缺点是部署麻烦，目标机器上必须有所需的库，而且版本不匹配会导致各种问题。

在Linux上，静态链接用.a文件，动态链接用.so文件。在Windows上，静态链接用.lib文件，动态链接用.dll文件。macOS上动态库是.dylib。

我个人的选择策略是：系统级工具和嵌入式程序用静态链接，桌面应用和服务器程序用动态链接。系统级工具追求部署简单，静态链接最省心；桌面应用和服务器程序需要频繁更新库，动态链接更灵活。

这里有一个常见的坑：动态库的版本兼容性。Linux上动态库通常有版本号，比如libfoo.so.1.2.3，其中1是主版本号，2是次版本号，3是修订号。主版本号不同的库不兼容，次版本号不同的库向后兼容。如果你编译时链接的是libfoo.so.1，运行时系统上只有libfoo.so.2，程序就会报error while loading shared libraries。

3.4 链接阶段的实操技巧与避坑指南

链接阶段的坑比编译阶段更多，而且报错信息往往更晦涩。这里分享几个我常用的技巧。

第一个技巧是用nm命令查看符号表。当你遇到undefined reference错误时，可以用nm看看目标文件或库里到底有没有这个符号：

nm main.o | grep printf nm libfoo.a | grep foo_init

nm的输出里，T表示已定义的文本符号，U表示未定义引用，W表示弱符号。如果符号是U，说明它被引用了但没有定义；如果根本找不到，说明这个符号压根不存在。

第二个技巧是用ldd查看动态库依赖。当你遇到运行时找不到库的问题时，可以用ldd看看可执行文件依赖哪些库，以及这些库能不能找到：

ldd ./myprogram

如果某个库显示not found，说明系统上缺少这个库，或者库的路径不在搜索路径里。

第三个技巧是用LD_LIBRARY_PATH临时指定库路径。开发阶段经常需要用自己的库替换系统库，这时候可以设置LD_LIBRARY_PATH环境变量：

export LD_LIBRARY_PATH=/path/to/my/libs:$LD_LIBRARY_PATH ./myprogram

不过要注意，LD_LIBRARY_PATH会影响所有程序，而且优先级高于系统默认路径，所以生产环境慎用。

第四个技巧是用-Wl,--verbose查看链接器的详细过程。当你搞不清楚链接器到底在干什么时，这个参数会打印出链接器搜索库的路径、加载的库、解析的符号等信息：

gcc main.o -o myprogram -Wl,--verbose

输出会非常多，但仔细看能发现很多有用的信息，比如链接器到底在哪些目录里找了库、找到了哪个版本的库。

第五个技巧是用-Wl,-Map=output.map生成链接映射文件。这个文件会列出每个符号的最终地址、每个目标文件贡献了哪些代码段和数据段。当你需要分析可执行文件的内存布局时，这个文件非常有用：

gcc main.o -o myprogram -Wl,-Map=output.map

4. 从可执行文件到进程：加载与运行时的那些事

4.1 可执行文件的格式：ELF、PE和Mach-O

可执行文件不是随便一堆二进制，它有严格的格式。Linux上用ELF（Executable and Linkable Format），Windows上用PE（Portable Executable），macOS上用Mach-O。这三种格式的设计理念类似，都包含文件头、段表、符号表、重定位表等内容。

以ELF为例，一个可执行文件通常包含以下段：

• .text：代码段，存放机器指令。
• .data：数据段，存放已初始化的全局变量和静态变量。
• .bss：未初始化数据段，存放未初始化的全局变量和静态变量。这个段在文件里不占空间，加载时由操作系统清零。
• .rodata：只读数据段，存放字符串常量和const变量。
• .symtab：符号表，存放符号信息。可执行文件里这个段通常会被剥离，以减小体积。
• .dynamic：动态链接信息，存放依赖的库和符号。

你可以用readelf -S来查看可执行文件的段表：

readelf -S myprogram

输出会列出每个段的名称、类型、地址、偏移量、大小等信息。

4.2 程序加载：操作系统如何把可执行文件变成进程

当你双击一个可执行文件或者在命令行里运行它时，操作系统会做以下事情：

1. 读取可执行文件头，检查格式是否合法、架构是否匹配。
2. 创建进程地址空间，为代码段、数据段、堆、栈分配虚拟内存。
3. 映射可执行文件到内存，把代码段和数据段映射到进程地址空间。注意这里是“映射”而不是“复制”，实际物理内存只在访问时才分配。
4. 加载动态库，如果可执行文件依赖动态库，加载器会找到这些库并映射到进程地址空间。
5. 重定位，修改代码和数据中的地址，使其指向正确的运行时地址。
6. 跳转到入口点，把控制权交给程序的入口函数（通常是_start，然后调用main）。

这个过程涉及很多细节，但日常开发中你只需要知道：程序加载时地址会变，所以不要依赖固定的绝对地址。如果你需要获取某个函数或变量的运行时地址，用&操作符或者dlsym函数。

4.3 动态库的加载与符号解析：运行时链接的细节

动态库的加载有两种方式：启动时加载和运行时加载。

启动时加载是默认方式，可执行文件在启动时由加载器自动加载所有依赖的动态库。这种方式简单，但启动慢，而且如果某个库缺失，程序直接启动失败。

运行时加载是用dlopen函数手动加载动态库，用dlsym获取符号地址。这种方式灵活，可以在需要时才加载库，而且可以处理库缺失的情况。很多插件系统就是用这种方式实现的。

#include <dlfcn.h> void *handle = dlopen("./libfoo.so", RTLD_LAZY); if (!handle) { fprintf(stderr, "Error: %s\n", dlerror()); return 1; } typedef int (*foo_func_t)(int); foo_func_t foo = (foo_func_t)dlsym(handle, "foo"); if (!foo) { fprintf(stderr, "Error: %s\n", dlerror()); dlclose(handle); return 1; } int result = foo(42); dlclose(handle);

编译时需要加-ldl参数：

gcc main.c -o main -ldl

这里有一个常见的坑：dlsym返回的符号地址可能为NULL，而且NULL也可能是合法的符号地址。所以判断dlsym是否成功不能只看返回值，还要用dlerror检查：

dlerror(); // 清除之前的错误 foo_func_t foo = (foo_func_t)dlsym(handle, "foo"); const char *error = dlerror(); if (error != NULL) { fprintf(stderr, "Error: %s\n", error); return 1; }

4.4 运行时常见问题排查实录

运行时和链接相关的问题主要有三类：找不到库、找不到符号、版本不匹配。

找不到库的典型报错是error while loading shared libraries: libfoo.so.1: cannot open shared object file: No such file or directory。解决办法有三种：把库放到系统默认搜索路径（如/usr/lib）、设置LD_LIBRARY_PATH环境变量、在编译时用-Wl,-rpath指定运行时库路径。

-Wl,-rpath是最推荐的方式，因为它把库路径写进了可执行文件，不需要依赖环境变量：

gcc main.o -o myprogram -L/path/to/libs -lfoo -Wl,-rpath=/path/to/libs

找不到符号的典型报错是undefined symbol: foo。这通常是因为动态库版本不对，或者符号被隐藏了。可以用nm -D查看动态库导出的符号：

nm -D libfoo.so | grep foo

如果符号前面是T，说明已导出；如果是t，说明是局部符号，没有导出。C++里可以用extern "C"或者__attribute__((visibility("default")))来控制符号导出。

版本不匹配的典型报错是version 'GLIBC_2.29' not found。这是因为可执行文件依赖的库版本比系统上的新。解决办法是升级系统库，或者用旧版本的工具链重新编译。我一般会在Docker容器里编译，确保编译环境和运行环境一致。

5. 编译链接全流程的实战建议

5.1 构建系统选型：Make、CMake还是其他

搞懂编译链接原理后，你可能会想：难道每次都要手动敲gcc命令吗？当然不是。实际项目都会用构建系统来管理编译链接过程。

Make是最经典的构建工具，用Makefile描述依赖关系和构建规则。优点是简单直接，几乎所有Unix系统都自带。缺点是语法晦涩，跨平台支持差，大型项目管理困难。

CMake是目前最流行的跨平台构建系统，用CMakeLists.txt描述项目结构，然后生成Makefile或Visual Studio工程文件。优点是跨平台、功能强大、生态丰富。缺点是学习曲线陡峭，生成的构建文件有时候难以调试。

Ninja是一个专注于速度的构建系统，通常和CMake配合使用。CMake生成Ninja文件，Ninja执行构建。优点是速度快，适合大型项目。缺点是功能简单，不适合单独使用。

我个人的建议是：小型项目用Make，中大型项目用CMake+Ninja。CMake虽然复杂，但它的跨平台能力和生态是其他工具无法比拟的。而且CMake的target_link_libraries命令能很好地管理链接依赖，避免手动指定库顺序的麻烦。

5.2 编译链接参数的实战配置

实际项目中，编译链接参数的选择直接影响程序的性能、体积和可调试性。这里分享一套我常用的参数配置。

编译参数：

CFLAGS="-Wall -Wextra -Werror -O2 -g -fPIC"

• -Wall -Wextra：开启大部分警告，尽早发现问题。
• -Werror：把警告当成错误，强制修复。这个在CI环境里特别有用。
• -O2：优化级别，平衡性能和编译时间。
• -g：生成调试信息，方便用gdb调试。
• -fPIC：生成位置无关代码，编译动态库时必须加。

链接参数：

LDFLAGS="-Wl,-rpath,'$ORIGIN/lib' -Wl,-z,now -Wl,-z,relro"

• -Wl,-rpath,'$ORIGIN/lib'：指定运行时库路径为可执行文件所在目录的lib子目录。$ORIGIN是ELF的一个特殊变量，表示可执行文件所在目录。
• -Wl,-z,now：立即绑定所有符号，而不是延迟绑定。这样能尽早发现符号缺失问题，但会稍微增加启动时间。
• -Wl,-z,relro：开启只读重定位，提高安全性。

这些参数不是绝对的，你需要根据项目特点调整。比如嵌入式项目可能更关注体积，那就用-Os而不是-O2；服务器项目可能更关注性能，那就用-O3加上-march=native。

5.3 编译链接问题的通用排查思路

遇到编译链接问题时，我一般按以下顺序排查：

1. 看报错信息。编译器的报错信息通常很准确，直接告诉你哪个文件哪一行出了什么问题。链接器的报错信息有时候比较晦涩，但仔细看也能找到线索。
2. 确认编译命令。用make VERBOSE=1或者cmake --build . --verbose查看实际执行的编译命令，确认参数是否正确。
3. 检查符号表。用nm查看目标文件和库的符号表，确认符号是否存在、是否导出。
4. 检查库依赖。用ldd查看可执行文件的库依赖，确认所有库都能找到。
5. 最小化复现。如果问题复杂，尝试写一个最小的复现用例，排除其他因素的干扰。
6. 搜索报错信息。如果以上步骤都没解决，把报错信息复制到搜索引擎里搜一下，通常能找到类似问题的讨论。

这里有一个我踩过的坑：编译器和链接器的版本不匹配。有一次我用gcc 9编译目标文件，用gcc 11链接，结果报了一堆奇怪的符号错误。后来发现是gcc 11默认开启了某些新的链接选项，和gcc 9生成的目标文件不兼容。解决办法是确保编译和链接用同一个版本的编译器。

5.4 编译链接优化的进阶技巧

当你对编译链接流程比较熟悉后，可以尝试一些进阶优化技巧。

链接时优化（LTO）是让编译器在链接阶段做跨模块优化。传统的编译模式下，编译器一次只能看到一个.c文件，无法做跨文件的优化。LTO把优化推迟到链接阶段，这时候编译器能看到所有目标文件，可以做更激进的优化，比如跨文件内联、死代码消除等。

开启LTO的方法是在编译和链接时都加-flto参数：

gcc -flto -O2 -c main.c -o main.o gcc -flto -O2 main.o -o myprogram

LTO能显著提升性能，但也会增加编译链接时间，而且有时候会触发编译器的bug。我一般会在发布版本里开启LTO，开发版本里关闭。

函数重排是另一种优化技巧，通过调整函数在可执行文件中的布局，提高指令缓存的命中率。GCC支持用-freorder-functions参数开启函数重排，但效果取决于具体的代码结构。

二进制压缩是用UPX等工具压缩可执行文件，减小体积。压缩后的可执行文件在运行时需要先解压，所以启动会慢一点，但体积能减小50%以上。嵌入式项目里比较常用。

6. 几个我踩过的编译链接坑

6.1 头文件循环包含导致的编译失败

头文件循环包含是新手最容易踩的坑。比如a.h包含b.h，b.h又包含a.h，编译器就会陷入无限循环，直到报错。

解决办法是用头文件保护宏：

#ifndef A_H #define A_H #include "b.h" // ... #endif

或者用#pragma once（非标准但主流编译器都支持）：

#pragma once #include "b.h" // ...

不过头文件保护宏只能防止重复包含，不能解决循环依赖。如果a.h和b.h真的互相依赖，你需要重新设计接口，比如用前向声明代替包含：

// a.h #ifndef A_H #define A_H struct B; // 前向声明 struct A { struct B *b; }; #endif

6.2 静态库链接顺序导致的undefined reference

前面提过，链接器从左到右扫描库文件，遇到未定义符号时才会去后面的库里找。所以如果库A依赖库B，命令行里库A要写在库B前面。

但有时候依赖关系比较复杂，手动调整顺序很麻烦。这时候可以用--start-group和--end-group把一组库包起来，链接器会在这组库里反复扫描，直到所有符号都解析完：

gcc main.o -o myprogram -Wl,--start-group -lA -lB -lC -Wl,--end-group

这个技巧在链接大型项目时特别有用，能省去很多调整库顺序的时间。

6.3 动态库符号冲突导致的运行时崩溃

动态库符号冲突是一个比较隐蔽的问题。当两个动态库导出同名符号时，先加载的库的符号会覆盖后加载的库的符号，导致后加载的库行为异常。

解决办法是用-Wl,-Bsymbolic参数让动态库优先使用自己的符号，而不是全局符号：

gcc -shared -fPIC -Wl,-Bsymbolic -o libfoo.so foo.o

或者用dlopen的RTLD_DEEPBIND标志，让库优先使用自己的符号：

void *handle = dlopen("./libfoo.so", RTLD_LAZY | RTLD_DEEPBIND);

不过RTLD_DEEPBIND不是所有系统都支持，用之前要确认一下。

6.4 编译缓存导致的“改了代码没生效”

有时候你改了代码，重新编译运行，发现行为没变。这通常是编译缓存导致的。

Make会根据文件时间戳判断是否需要重新编译。如果头文件改了但.c文件没改，Make可能不会重新编译依赖这个头文件的.c文件。解决办法是用-MMD -MP参数生成依赖文件，让Make知道头文件和.c文件的依赖关系：

CFLAGS="-MMD -MP"

或者在CMake里用CMAKE_DEPENDS_USE_COMPILER选项。

另一个可能是ccache导致的。ccache会缓存编译结果，如果缓存命中就直接返回旧结果。解决办法是用ccache -C清空缓存，或者用CCACHE_DISABLE=1临时禁用ccache。

6.5 跨平台编译的注意事项

跨平台编译时，编译链接的差异会带来很多问题。比如Windows上动态库需要显式导出符号，而Linux上默认所有符号都导出。Windows上用__declspec(dllexport)导出符号，用__declspec(dllimport)导入符号：

#ifdef _WIN32 #ifdef BUILDING_DLL #define API __declspec(dllexport) #else #define API __declspec(dllimport) #endif #else #define API __attribute__((visibility("default"))) #endif API int foo(int x);

另外Windows上路径分隔符是反斜杠，Linux上是正斜杠；Windows上可执行文件后缀是.exe，Linux上没有后缀。这些差异在写跨平台构建脚本时都要考虑到。

我一般会用CMake的if(WIN32)和if(UNIX)来处理平台差异，把平台相关的代码隔离到单独的模块里，主逻辑保持平台无关。这样代码更清晰，也更容易维护。