静态库与动态库从原理到实战：制作、链接与避坑指南

让程序编译通过只需要头文件，但链接通过就得靠库文件。这个道理说起来简单，但真正动手做一遍静态库和动态库，你会发现坑远比自己想象的多。这篇文章把我踩过的坑、验证过的方法全部整理出来，从原理到实操，从Windows到Linux，从桌面端到STM32嵌入式，一次性把动静态库的制作与使用讲透。

1. 先搞清楚：静态库和动态库到底差在哪

很多人刚开始接触库这个概念时，总会把“.a”“.lib”“.so”“.dll”混为一谈，觉得反正都是别人编译好的代码，我链接上能用就行。但真出了问题，比如运行时提示找不到动态库，或者链接时一堆未定义符号，才知道自己其实没搞懂这些文件背后的机制。

1.1 两个库的本质区别

静态库和动态库最核心的区别在于“链接的时机不同”。

静态库在程序链接阶段就被完整复制进可执行文件里。比如你用gcc编译main.c并链接libfoo.a，最终生成的main可执行文件里已经包含了libfoo.a中需要的所有机器码。之后运行main时，系统完全不需要libfoo.a这个文件。

动态库则完全相反。链接动态库时，程序只在可执行文件里记录了动态库的名字、路径和一些符号信息，并不会把库的代码复制进来。等到程序真正运行，由动态链接器去内存中加载这些动态库文件。所以一旦运行时找不到对应的so或dll，程序就会直接启动失败。

这个差异带来了一系列连锁影响：

• 可执行文件大小不同。静态链接生成的文件体积大，动态链接生成的文件体积小。
• 部署方式不同。静态链接只要分发一个可执行文件就行，动态链接必须把依赖的库一起带上。
• 内存占用不同。多个程序共享同一个动态库时，操作系统只在物理内存里加载一份库代码，节省内存。这也是动态库最被看重的优势之一。
• 升级方式不同。动态库可以单独替换，程序无需重新编译；静态库一旦发现Bug，所有依赖它的程序都得重新编译链接。
• 兼容性风险不同。动态库版本升级可能带来ABI兼容问题，经典的就是“DLL Hell”和Linux下的GLIBC版本不兼容问题。

1.2 为什么会有“编译时好好的，链接却报错”

这个现象太常见了。新手最容易困惑的是：我已经把头文件include进来了，编译也通过了，怎么链接时报“undefined reference to xxx”？

这里要理清楚一个概念：编译和链接是两回事。

编译阶段，编译器只需要看到函数的声明，也就是头文件里那行void foo();，就能把调用foo的代码编译成一段机器指令——这段指令其实就是“跳转到foo这个地址去执行”，但此时编译器并不知道foo的实际地址是多少，所以这个地址是空的，需要链接器在后面填充。

链接阶段，链接器要找到foo的具体实现代码，也就是符号的“定义”。头文件里只有声明，没有实现，所以必须去一个或多个库文件里寻找foo的定义。如果找遍所有的库都找不到，就直接报undefined reference。

反过来还有一种常见错误是“multiple definition of xxx”，意思是同一个符号在多个库或者目标文件里出现了重复定义。这个一般出现在同时链接了几个相互包含相同代码的库，或者静态库的顺序不对导致符号被重复提取。关于静态库链接顺序的问题，后面我会专门说明。

2. 制作静态库：从源码到.a/.lib

静态库的制作相对于动态库要简单很多，本质上就是把一堆.o目标文件打包成一个归档文件，不涉及符号重定位和导出表这些复杂机制。下面按照Linux和Windows两个环境分别说明。

2.1 Linux下制作静态库的三步流程

假设我有两个源文件add.c和sub.c，分别实现了两个数学运算函数，头文件是mymath.h。整个制作过程就三步：

第一步，编译出位置无关的和普通的目标文件。这里需要特别说明一点：从用途上讲，静态库的目标文件其实不需要使用-fPIC参数，但如果这个静态库将来还想被链接进动态库或者共享库，那编译时加上-fPIC会稳妥得多。因为共享库要求其中的所有可重定位目标代码都是位置无关的。

第二步，用ar命令把目标文件打包成归档文件，同时生成符号索引：

bash复制gcc -c -fPIC add.c sub.c
ar rcs libmymath.a add.o sub.o
ranlib libmymath.a

ar rcs里面三个参数的含义：

• r表示如果归档中已经有同名文件就替换；
• c表示创建归档文件，如果有提示信息不显示；
• s表示在归档中写入符号索引表，方便链接器快速查找符号。

其实ar rcs的s选项已经等同于ranlib了，但很多Makefile里还是会再单独执行一次ranlib，这个无伤大雅，相当于双保险。如果你想查看libmymath.a里到底有些什么，可以直接运行ar t libmymath.a查看包含的目标文件列表，或者用nm -s libmymath.a查看符号索引表。

第三步，把这个静态库和头文件放到约定的目录，比如/usr/local/lib和/usr/local/include。

Linux下还有一个环节值得注意，就是如果静态库依赖了其他库，比如libmymath.a里有个函数调用了sqrt，那么链接时除了指定-lmymath，还要额外加-lm。静态库不会自动去解析它的依赖，这个依赖关系必须由最终链接可执行文件的命令显式给出。

2.2 Windows下制作静态库

Windows下用Visual Studio生成静态库要更图形化一些。新建一个“静态库”项目，把源码加进去，右键编译，就会生成一个.lib文件。这个.lib和Linux下的.a作用相同，都是静态库。

不过Windows下的.lib有一种特殊情况：有些.lib文件其实不是真正的静态库，而是“导入库”。导入库里面并没有函数的实现代码，它只记录了动态库.dll里导出的符号信息，链接器通过导入库知道某个符号在哪个dll里，运行时会去那个dll里加载。这跟静态库完全是两码事，但文件后缀恰好都是.lib，所以经常有人搞混。

怎么区分一个.lib到底是静态库还是导入库呢？如果是Visual Studio环境，可以用命令dumpbin /headers xxx.lib查看文件头，静态库的成员通常是COFF格式的目标文件，而导入库会显示“Import字样。如果是MinGW工具链，.a后缀的文件也可能是导入库，用objdump -x可以看到DLL Name`字段。

2.3 静态库链接顺序的坑

静态库的链接顺序问题是最隐蔽、最坑人的，几乎没有之一。

先理解一下链接器处理静态库的方式：gcc在链接时扫描参数列表中的库文件，如果某个静态库中目前还没有被需要的符号，那么这个库文件里的目标文件就不会被提取进最终程序。注意“目前还没有被需要”这个条件是动态变化的，后面的源文件可能又引用了新符号，但此时前面已经扫描过的库不会再被重新扫描一遍。

所以链接命令里库的顺序非常重要。经典的规则是：被依赖的库放在后面，主动依赖别人的库放在前面。比如我写了一个main.c，调用了libA.a里的函数，libA.a又调用了libB.a里的函数，那链接命令应该是：

bash复制gcc main.o -lA -lB -o app

如果把-lA -lB的顺序反过来，就很有可能报undefined reference，因为链接器扫描到libB.a时，main.o还没有被处理完（或者还没被确定需要libB里的符号），libB没有被提取，等到了libA.a需要libB里的符号时，libB已经错过去了。

实际项目中库的依赖链可能很长，A依赖B，B依赖C，C依赖D，命令就必须写成-lA -lB -lC -lD。如果循环依赖，比如A依赖B、B也依赖A，那就只能重复写，或者使用链接器提供的--start-group和--end-group参数来包裹一组库，让链接器反复搜索直到解析完所有符号：

bash复制gcc main.o -Wl,--start-group -lA -lB -Wl,--end-group -o app

这个技巧我在很多工程项目的Makefile里都见过，在解决复杂依赖环时非常有效。

3. 制作动态库：Windows和Linux都别踩坑

动态库的制作比静态库复杂不少，因为涉及符号可见性、导出表、重定位、运行时路径等一系列问题。但只要你理解了动态库“编译时只记录、运行时才加载”的本质，许多问题都能自己推导出答案。

3.1 Linux下制作.so的详细过程

还是拿上面的add和sub举例。制作动态库的命令：

bash复制gcc -c -fPIC add.c sub.c
gcc -shared -o libmymath.so add.o sub.o

第一条命令中-fPIC是必须加的，生成位置无关代码。第二条命令中-shared告诉编译器这次要把目标文件链接成共享库而不是可执行文件。

如果只想用一条命令完成：

bash复制gcc -shared -fPIC -o libmymath.so add.c sub.c

这里-fPIC的作用，读者可以去搜“为什么共享库必须用PIC”这样的背景知识。简单说，就是库被加载到内存时，它的内存地址每次运行可能都不一样，代码里的函数调用和全局变量访问就不能写死绝对地址，必须用相对寻址，这样才能保证不同进程加载到不同地址也能正常跑。

制作动态库之后，链接可执行文件：

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

注意，-lmymath会默认在标准库路径和-L指定路径下找libmymath.so。如果当前目录同时存在libmymath.so和libmymath.a，链接器默认优先选择动态库。

但如果你运行这段代码会立刻遇到一个问题——上面命令生成的app，运行时大概率会提示找不到libmymath.so。这是为什么？

因为链接器在生成app时，只记录了动态库的名字libmymath.so，并没有把库的完整路径写进app的可执行文件里。运行时动态链接器按照默认规则去搜索库：一般是/lib、/usr/lib、/etc/ld.so.conf里配置的路径，以及环境变量LD_LIBRARY_PATH指定的路径。当前目录不在默认搜索路径里，所以要手动指定：

bash复制export LD_LIBRARY_PATH=./
./app

还有一个更专业的做法是修改可执行文件的DT_RPATH或者DT_RUNPATH字段，在链接时写入相对路径或绝对路径：

bash复制gcc main.c -L. -lmymath -Wl,-rpath,/path/to/lib -o app

-Wl,-rpath会把路径信息嵌入到可执行文件中，运行时就优先从该路径下查找动态库。在开发阶段，LD_LIBRARY_PATH最方便；在交付部署阶段，rpath或直接修改系统库搜索路径才是合理的。

3.2 Windows下制作.dll：导出宏是绕不开的

Windows下用Visual Studio制作动态库，关键点在于“导出”。函数如果想要被dll外部使用，必须显式导出。最常用的方式是使用__declspec(dllexport)和__declspec(dllimport)搭配宏定义。

典型的做法是定义一个头文件：

c复制#ifdef MYMATH_EXPORTS
#define MYMATH_API __declspec(dllexport)
#else
#define MYMATH_API __declspec(dllimport)
#endif

MYMATH_API int add(int a, int b);
MYMATH_API int sub(int a, int b);

在编译dll的工程里，定义预处理宏MYMATH_EXPORTS，这样头文件里的函数声明会变成__declspec(dllexport)，告诉编译器这些函数要导出到dll里。在使用dll的工程里，不定义这个宏，函数声明就变成__declspec(dllimport)，告诉编译器这些函数的实现来自外部dll。

这套宏定义几乎是所有Windows动态库项目的标配。之所以要区分导出和导入，是因为Windows PE格式的dll不像ELF so那样默认导出所有符号，开发人员必须显式定义哪些符号对外可见。如果没有加__declspec(dllexport)，即使生成了dll，外部程序也链接不上。这个可以从dumpbin /exports xxx.dll命令查看导出表来验证。

我见过很多人在Windows下被这个问题卡住半天，其实原因就是这个导出宏没写对。Linux下不需要这个宏，所以很多从Linux转到Windows的开发者会很不适应。

3.3 符号可见性控制：Linux其实也有

话说回来，Linux下虽然默认所有全局符号都对外可见，但在大项目中，这种“全裸”状态并不好。一来暴露了太多内部实现细节，二来可能造成符号冲突。比如你的.so里有个内部函数叫debug_print，另一个库恰好也有同名函数并且先被加载，那么你的库在调用debug_print时可能就链接到了别人的函数上。

现代编译器和链接器提供了控制符号可见性的手段。最常用的就是-fvisibility=hidden编译选项，配合__attribute__((visibility("default")))显式标记对外符号：

c复制#define MYMATH_API __attribute__((visibility("default")))

MYMATH_API int add(int a, int b);

编译时统一加-fvisibility=hidden，那么默认所有符号都是隐藏的，只有标记了visibility("default")的函数才会被导出。这种模式在用CMake组织的C/C++项目中越来越流行，也是许多专业库的标准做法。

用nm -D libxxx.so可以查看共享库的导出符号表，如果看到一堆t（本地符号）和T（全局文本符号），就要留意是不是把内部符号也导出了。只保留必要的导出符号，既能减少动态链接器符号解析的负担，也能避免符号污染带来的诡异问题。

4. 使用动态库：链接、打包、运行时找不到

制作库还不是最麻烦的，真正的考验在使用阶段。这一节主要回应一下网友搜得最多的几个问题：QT项目里怎么指定链接的库？运行时提示找不到动态库怎么办？CMake里怎么处理？我把这些场景全部梳理一遍。

4.1 两种使用方式：编译期链接与运行时加载

动态库的使用有两种完全不同的方式，第一种是“编译期链接”，第二种是“运行时加载”。

编译期链接，指的是程序编译链接时就指定链接某个动态库。比如gcc命令中加-lmymath，或者Visual Studio中配置附加依赖项。这种方式要求编译时有头文件和导入库（Linux下直接链接.so文件，Windows下通常链接.lib导入库）。运行时，动态链接器会负责找到真正的dll/so并加载。

运行时加载，则是程序运行过程中主动调用dlopen/LoadLibrary读取动态库，再用dlsym/GetProcAddress取出函数地址来调用。这种方式不要求在编译期知道动态库的函数签名，常用于插件系统、功能开关和按需加载。

这两种方式各有适用场景。插件架构必须用运行时加载，比如一个编辑器要支持多种图像格式，每种格式写一个dll/so，程序启动时扫描目录并动态加载。而如果只是正常的依赖一个库，用编译期链接就够了，代码写起来更直接，编译器也能做更多类型检查。

4.2 Windows下QT项目pro文件怎么指定链接静态库

网友问“windows qt pro文件怎么指定链接静态库”，这个场景非常具体。在Qt的.pro文件中，可以用LIBS变量来指定库。

假设我在Windows上编译一个项目，要链接一个名为MyLib的静态库文件mylib.lib，库文件放在项目根目录下的mylib目录中，头文件放在mylib/include目录中，pro文件可以这样写：

pro复制INCLUDEPATH += $$PWD/mylib/include

LIBS += -L$$PWD/mylib -lMyLib

或者直接写绝对路径：

pro复制LIBS += $$PWD/mylib/mylib.lib

两种写法都可以。不过有几点要特别注意：在Windows上，如果该lib是MinGW工具链生成的，文件名通常叫libmylib.a，那么-lmylib也能匹配到；如果是MSVC工具链生成的，后缀是.lib。如果在Qt Creator中同时装了MSVC和MinGW两套工具链，要严格保证库和编译器的ABI一致，否则会报一堆unresolved external symbol或者file format not recognized之类的错误。

另外还有一个容易误导人的地方：如果你要链接的是“导入库”，在pro文件中的写法其实和静态库一模一样，都是LIBS += -Lpath -lname。所以确认自己链接的到底是不是静态库，不能光看pro文件，还得回到上一节讲的方法去检查文件本身。

4.3 CMake中链接动静态库的标准写法

现在很多新项目用CMake而不是手写Makefile或pro文件。CMake中链接库的写法非常统一，先创建目标，再用target_link_libraries指定依赖库：

cmake复制add_executable(app main.cpp)
target_link_libraries(app PRIVATE mymath)

如果库是自定义的静态库：

cmake复制add_library(mymath STATIC add.c sub.c)
add_executable(app main.cpp)
target_link_libraries(app PRIVATE mymath)

如果要链接系统路径下的第三方库，可以用find_library或find_package：

cmake复制find_library(MYMATH_LIB mymath)
find_path(MYMATH_INCLUDE_DIR mymath.h)

add_executable(app main.cpp)
target_link_libraries(app PRIVATE ${MYMATH_LIB})
target_include_directories(app PRIVATE ${MYMATH_INCLUDE_DIR})

CMake在处理动态库和静态库时的差异主要体现在运行时路径的处理上。CMake默认在build目录下运行程序时，会帮我们把动态库的路径写进rpath，所以很多时候在本地跑没有任何问题，但把程序拷贝到别的机器，或者直接把build目录下的可执行文件拿出去用，就会遇到找不到.so/.dll的问题。

针对这种情况，通常的做法是在CMake中设置安装规则，通过install(TARGETS ...)把可执行文件和动态库一起安装到指定目录，并设置合适的rpath。如果只是临时让程序跑起来，在Linux下设置LD_LIBRARY_PATH最省事，但这属于开发期方案，不适合正式交付。

4.4 动态库运行时找不到的排查思路

“运行时找不到动态库”这个问题几乎每个人都会遇到，而且Windows、Linux的表现形式不一样，排查思路也完全不同。

Linux下，运行程序出现类似error while loading shared libraries: libmymath.so: cannot open shared object file: No such file or directory，排查手段很明确：

首先用ldd app查看可执行文件依赖的所有动态库，输出中如果某一行显示not found，就说明这个库没找到。然后用LD_LIBRARY_PATH=/path/to/lib ./app临时指定路径验证。如果能跑起来，再把路径写入系统配置文件/etc/ld.so.conf.d/下新建一个自定义conf文件，最后执行ldconfig刷新缓存。

Windows下，程序启动时如果弹出“由于找不到xxx.dll，无法继续执行代码”，排查手段则侧重于确认dll是否在当前目录或系统搜索路径中。Windows的dll搜索顺序大致是：程序所在目录、系统目录、Windows目录、环境变量PATH指定的目录。最简单省事的方法是把dll放在和exe相同目录下，这也是绝大多数软件分发时采用的做法。

对于使用Qt项目的场景，动态库的选择会多一点。Qt的windeployqt工具可以自动将Qt程序依赖的运行库提取出来放到exe同目录下，但它往往只处理Qt自身的库，第三方库还是要手动拷贝。

5. 特殊场景实战：从桌面端到嵌入式

库的制作和使用不只是桌面软件领域的事。嵌入式环境，特别是STM32这种ARM Cortex-M平台，静态库的运用也非常广泛。有人搜“stm32制作静态库”，大概就是因为供应商提供的库文件是编译好的.a，自己也想把核心算法封装成库来保护源码。

5.1 STM32中制作和使用静态库的要点

STM32开发中，常用IDE是Keil MDK、IAR和STM32CubeIDE。后面两个工具链分别基于GCC和armcc，但静态库的概念完全一致。

举STM32CubeIDE的例子，它是一个基于Eclipse+GCC的IDE，工具链是arm-none-eabi-gcc。假设我有一个algorithm.c实现了PID控制算法，想封装成静态库libpid.a，编译的时候用arm-none-eabi-gcc：

bash复制arm-none-eabi-gcc -c -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -Os algorithm.c -o algorithm.o
arm-none-eabi-ar rcs libpid.a algorithm.o

这里关键的是编译参数必须和最终应用工程保持一致，尤其是芯片型号、浮点运算类型，如果主程序用了硬件浮点而库里用软浮点编译，链接时会出现usesVFP register arguments这类错误，非常折磨人。

在Keil MDK中，你不需要手写这些命令，只需在工程中编译一个Static Library目标，Keil会帮你把当前工程编译成.lib，然后在其他工程中把该.lib加入链接。但要注意，用ARMCC编译的库，GCC工具链是不能直接用的，编译器版本、ARM架构版本和ABI标准都必须匹配。这也是为什么芯片厂商提供的固件库通常要区分Keil、IAR、GCC三种版本。

STM32开发里使用静态库最大的优势就是部署简单。生成bin/hex烧录到单片机后，程序运行不依赖任何外部库文件，所有代码都在Flash里，非常适合固件这种不需要热更新的场景。

5.2 用onnxruntime动态库做推理的链接经验

最近深度学习推理部署很热门，onnxruntime发布时就同时提供了动态库。我以Linux下的libonnxruntime.so为例，讲述怎么在项目中链接并正确配置运行时。

onnxruntime的C++接口使用非常直观，但编译链接时要处理三个问题：头文件路径、库路径、运行时路径。

bash复制g++ main.cpp -I/path/to/onnxruntime/include -L/path/to/onnxruntime/lib -lonnxruntime -Wl,-rpath,/path/to/onnxruntime/lib -o inference_app

如果是在CMake工程中：

cmake复制find_path(ONNX_INCLUDE_DIR "onnxruntime_cxx_api.h")
find_library(ONNX_LIBRARY "onnxruntime")
add_executable(inference_app main.cpp)
target_link_libraries(inference_app PRIVATE ${ONNX_LIBRARY})
target_include_directories(inference_app PRIVATE ${ONNX_INCLUDE_DIR})

运行时，如果程序报告找不到libonnxruntime.so，最简单的解决方式是在执行脚本中动态设置库路径：

bash复制export LD_LIBRARY_PATH=/path/to/onnxruntime/lib:$LD_LIBRARY_PATH
./inference_app

这里有个很容易被忽略的坑：onnxruntime的CPU版本和GPU版本是不同编译产物的，CPU版依赖较少，GPU版还会依赖CUDA、cuDNN等一系列动态库。如果机器上缺少这些依赖，运行时的报错信息和onnxruntime本身无关，而是提示找不到libcudnn.so之类的库。排查这类问题时，可以跑一下onnxruntime自带的样例程序，确认基本库路径无误，再逐级排查CUDA相关依赖。

Windows上使用onnxruntime则简单不少，官方发布包里有onnxruntime.dll和onnxruntime.lib导入库，编译时需要保证Visual Studio版本和库的编译工具链匹配，比如Release版的exe不要链接Debug版的lib，否则会有_ITERATOR_DEBUG_LEVEL的错误。

5.3 混合链接：同一个程序既要静态库又要动态库

真实的项目很少只用一种库。我做过一个数据分析工具，里面用了几个自研的算法模块，为了隐藏源码用了静态库；又接了onnxruntime做模型推理，用的是动态库。两者混链时有一些经验值得分享。

首先，命名冲突问题。如果静态库和动态库中存在同名符号，而且链接顺序不合理，最终可执行文件解析符号的规则会非常难判断。要主动控制导出符号，静态库内部符号最好加static限定，或者通过编译选项控制隐藏，避免污染运行时符号表。

其次，编译选项的一致性。混合链接时，不仅要关心库本身的ABI，还要注意编译宏、C++标准版本、线程模型等是否一致。比如一个库用C++11编译，另一个用C++17编译，通常情况下都能正常链接，但如果库的公共接口里有std::string等标准库类型，两个库链接的libstdc++版本差异就可能引发问题。

第三，部署清单。混合链接的动态库可能不止一两个，建议在交付时可执行程序的同目录下放一份README，把每个动态库的版本、来源、GCC版本写清楚，否则三个月后你自己都搞不清楚当时是怎么配起来的。

6. 一套封装动态库的脚本模板

这部分分享一个我一直在用的通用shell脚本，用来在Linux下同时生成静态库和动态库，并正确处理符号可见性。脚本的精髓在于“一份源码，两种库”，编译选项统一，方便维护。

bash复制#!/bin/bash

SRC="add.c sub.c"
OUT_LIB_DIR="./lib"
INC_DIR="./include"
SONAME_MAJOR=1
SONAME_MINOR=0
LIBNAME=mymath

gcc -c -fPIC -O2 -fvisibility=hidden $SRC
gcc -shared -Wl,-soname,lib${LIBNAME}.so.${SONAME_MAJOR} -o lib${LIBNAME}.so.${SONAME_MAJOR}.${SONAME_MINOR} *.o
gcc -c -O2 $SRC
ar rcs lib${LIBNAME}.a *.o
ranlib lib${LIBNAME}.a

mv lib${LIBNAME}.a ${OUT_LIB_DIR}/
ln -sf lib${LIBNAME}.so.${SONAME_MAJOR}.${SONAME_MINOR} ${OUT_LIB_DIR}/lib${LIBNAME}.so.${SONAME_MAJOR}
ln -sf lib${LIBNAME}.so.${SONAME_MAJOR}.${SONAME_MINOR} ${OUT_LIB_DIR}/lib${LIBNAME}.so

rm -f *.o

脚本里-Wl,-soname设置了动态库的SONAME，这算是Linux动态库管理里比较进阶的一块知识。SONAME决定了程序运行时动态链接器去找哪个文件名的库，也决定了库升级时哪些程序不受影响。设置了SONAME后，可执行文件记录的依赖名是libmymath.so.1，而不是libmymath.so。这样升级到libmymath.so.2时，老程序不会因为默认链接到libmymath.so而被意外引入不兼容的代码。

但在实际开发中，如果项目就自己一个人用，这个SONAME设置的意义不大。可如果是面向第三方开发者的SDK，这个细节就非常重要。第三方程序链接之后，你发布一个不破坏ABI的小版本升级，直接替换libmymath.so.1.0为libmymath.so.1.1，把软链接指向新文件即可，老程序完全不受影响。

说到封装，我还想提一个SDK设计经验：头文件里只暴露必要的API，内部结构体尽量使用不透明指针。比如在头文件里这样写：

c复制typedef struct MyMathContext MyMathContext;

MyMathContext* mymath_create(void);
void mymath_destroy(MyMathContext* ctx);
int mymath_add(MyMathContext* ctx, int a, int b);

这样使用者不需要知道结构体内部长什么样，库的实现细节可以随时修改，只要保持函数签名不变，对外就是ABI兼容的。这个方法在Windows动态库和Linux动态库上都是通用的，能够很好地保持库的向后兼容性。

写在最后的实操经验

动静态库这块知识点看起来零碎，但核心就一句话：静态库是“代码复制”，动态库是“代码共享”。想清楚这句话，链接时的很多问题都能自己找到答案。

我个人的几个实操习惯可以给大家参考。第一，所有动态库项目从第一天起就设置好SONAME或者Windows下的导出宏，不要等到发布前才补，临时补的导出表大概率会漏函数。第二，产品代码的CMakeLists里不用LD_LIBRARY_PATH作为最终解决方案，它解决的是开发期的燃眉之急，但交付时要靠rpath、安装规则或者把动态库copy到固定目录才能真正解决问题。第三，拿到一个陌生库文件，先用file命令在Linux下看文件类型，再用nm或objdump看符号，确认它是静态库、导入库还是动态库，再决定怎么链接。

最后分享一个小技巧，排查链接问题时，在gcc编译命令加-Wl,--verbose可以看到链接器搜索库的详细过程，加了-Wl,--trace可以把链接器选择的每一个库文件路径都打印出来。这两个参数比任何工具体验都直接，能看到“到底链接了哪个路径下的哪个文件”，很多库混乱问题一下就明了了。