4、静态库与动态库：库的创建与使用、链接过程、库的版本管理
说到代码复用，库是绕不开的话题。我个人习惯把库看作「打包好的工具箱」——你写好了功能，别人拿来就能用，不用关心里面怎么实现的。但这里有个坑：静态库和动态库，用错了地方，项目可能直接崩掉。
我刚开始做嵌入式时，觉得库嘛，不就是把 .o 文件打个包？后来被坑过几次才明白，链接过程、版本管理，哪个环节出问题都够你喝一壶的。今天咱们就好好聊聊这个。
4.1 静态库：简单粗暴，但别滥用
静态库说白了就是把一堆 .o 文件打包成一个 .a 文件。链接时，链接器会把库中用到的代码直接复制到最终的可执行文件里。
创建静态库，其实就两步：
# 第一步：编译成目标文件
gcc -c -o mylib.o mylib.c
# 第二步：打包成静态库
ar rcs libmylib.a mylib.o嗯，这里要注意：库名必须遵循 libxxx.a 的命名规则。否则链接器会找不到它。
使用静态库，链接时指定库路径和库名：
gcc -o main main.c -L. -lmylib-L. 表示在当前目录找库，-lmylib 表示链接 libmylib.a。
静态库的特点：
- 可执行文件独立运行，不依赖外部库文件
- 多个程序使用同一静态库，每个程序都有一份副本，浪费空间
- 库更新了，所有使用它的程序都得重新链接
我在项目中遇到过这样一个场景：一个传感器驱动库，版本迭代特别快。如果用静态库，每次更新都得通知所有团队重新编译。那段时间，光协调版本就花了不少精力。
避坑指南：我曾经在调试一个内存泄漏问题时，发现静态库中的全局变量被多个模块共享，导致状态混乱。静态库中的全局变量，每个链接它的可执行文件都有一份独立副本。如果你期望共享状态，请用动态库。
4.2 动态库：灵活，但小心「地狱」
动态库（.so 文件）在链接时只记录符号引用，不复制代码。程序运行时才加载库。这样多个程序可以共享同一份库代码，节省内存。
创建动态库：
gcc -fPIC -c -o mylib.o mylib.c
gcc -shared -o libmylib.so mylib.o-fPIC 生成位置无关代码，这是动态库必需的。不加这个选项，库加载到内存时可能出问题。
使用动态库：
gcc -o main main.c -L. -lmylib编译命令和静态库一样。区别在于运行时：系统需要知道去哪里找 .so 文件。
你可以设置 LD_LIBRARY_PATH 环境变量，或者把库放到 /usr/lib 等标准路径下。
小技巧：我个人习惯在编译时用 -Wl,-rpath,. 把库搜索路径硬编码到可执行文件里。这样部署时不用额外配置环境变量：
gcc -o main main.c -L. -lmylib -Wl,-rpath,.4.3 链接过程：你以为是黑盒？其实有迹可循
链接过程到底干了什么？说白了就三件事：
- 符号解析：找到每个函数、全局变量的定义
- 重定位：把符号引用替换成实际地址
- 合并段：把多个目标文件的代码段、数据段合并
为什么会链接失败？最常见的原因是「未定义的引用」。你调了个函数，链接器翻遍所有库都找不到它的定义。
我曾经排查过一个链接问题：明明库里有这个函数，但链接器就是报 undefined reference。后来发现是库的链接顺序不对。GCC 链接器是从左到右扫描库的，如果 main.o 引用了 libB 中的函数，而 libB 又引用了 libA，那么顺序必须是 main.o -lB -lA。反过来就报错。
链接顺序规则：
- 被依赖的库放在后面
- 有循环依赖时，在命令行重复列出库
- 或者用
--start-group和--end-group包裹
4.4 库的版本管理：别让「地狱」找上门
动态库的版本管理，做不好就是「DLL 地狱」——程序 A 需要 libxxx.so.1，程序 B 需要 libxxx.so.2，系统里只有一个，总有一个跑不起来。
Linux 下的做法是使用 soname。每个动态库有三个名字：
| 名称 | 示例 | 说明 |
|---|---|---|
| real name | libmylib.so.1.0.1 | 实际文件，包含完整版本号 |
| soname | libmylib.so.1 | 嵌入到库中的名字，只包含主版本号 |
| linker name | libmylib.so | 编译时用的名字，软链接到 soname |
创建库时指定 soname：
gcc -shared -Wl,-soname,libmylib.so.1 -o libmylib.so.1.0.1 mylib.o然后创建软链接：
ln -s libmylib.so.1.0.1 libmylib.so.1
ln -s libmylib.so.1 libmylib.so程序运行时，系统根据 soname 找库。主版本号变了，说明接口不兼容，旧程序会报错。次版本号变了，说明新增了接口但向后兼容，旧程序还能用。
避坑指南：我曾经在升级一个库时，只改了文件名没改 soname。结果旧程序加载了新库，因为接口变了直接崩溃。从那以后，我每次发布新版本都会检查 soname 是否正确。
4.5 静态库 vs 动态库：怎么选？
你想想看，嵌入式系统资源有限，怎么选其实有套路：
| 场景 | 推荐 | 原因 |
|---|---|---|
| 系统只有一个程序用这个库 | 静态库 | 省去动态加载的开销 |
| 多个程序共享库 | 动态库 | 节省内存和 Flash |
| 库需要频繁更新 | 动态库 | 只替换 .so 文件，不用重新编译程序 |
| 实时性要求极高 | 静态库 | 避免动态加载的延迟 |
| 库是第三方闭源的 | 静态库 | 部署简单，不用操心版本依赖 |
嗯，这里要注意：有些嵌入式 RTOS 根本不支持动态加载。所以先看平台，再选方案。
我的个人习惯：在项目初期，我会先用静态库，简单直接。等系统稳定了，如果发现多个程序确实需要共享代码，再改成动态库。别一开始就上动态库，版本管理会把你搞疯的。
好了，关于静态库和动态库，今天就聊这么多。记住一句话：库是工具，不是目的。选对了，项目顺风顺水；选错了，后面全是坑。