静态库仅归档目标文件，不解析依赖；链接时必须显式列出所有依赖的第三方静态库，且按从左到右依赖倒序排列，否则报undefined reference。
gcc链接静态库时无法找到第三方库符号
静态库本身不包含依赖关系，ar 打包只合并 .o 文件，不会解析或嵌入它所依赖的第三方函数。如果你的 math_util.c 里调用了 libz.a 中的 compress()，直接用 ar rcs libmath.a math_util.o 生成的静态库仍是“不完整”的——链接器在最终链接可执行文件时才会报错：undefined reference to 'compress'。
- 静态库不是“可执行片段”，它只是目标文件的归档，不解决符号依赖
- 第三方静态库（如
libz.a、libssl.a）必须显式参与最终链接，不能靠“打包进主静态库”来隐藏 -
-static选项控制的是最终可执行文件是否全静态，不影响中间静态库的构建过程
正确做法：把第三方静态库放在最终链接命令末尾
假设你写了 my_crypto.c，它依赖 OpenSSL 的 libcrypto.a，你已经把它编译为 my_crypto.o 并打包成 libmycrypto.a。但这个 libmycrypto.a 不能单独使用——你必须在构建可执行文件时，同时提供它和它依赖的第三方静态库：
gcc main.c -L. -lmycrypto -L/usr/lib -lcrypto -lz -o program
- 顺序很重要：
-lmycrypto必须放在-lcrypto和-lz前面，因为链接器从左到右扫描，只“记住”尚未满足的符号 -
-L要对应每个库的实际路径；系统库（如/usr/lib）通常不用加-L，但若用自定义安装路径（如/opt/openssl/lib），就必须显式指定 - 如果第三方库也有依赖（比如
libcrypto.a依赖libz.a），它们也得列在命令里，且按依赖倒序排列（被依赖的放右边）
Makefile里链接多个静态库的常见错误
很多人在 Makefile 中写 LDFLAGS = -lmycrypto -lcrypto，然后 $(CC) $^ $(LDFLAGS) -o $@，结果仍报 undefined symbol。问题往往出在两点：
-
$^展开的是所有依赖目标（如main.o utils.o），但没包含任何.a库；LDFLAGS是传递给链接器的选项，但它不自动把库“加进去”，只是告诉链接器“去哪找、找什么” - 漏掉
-static时，链接器默认优先选.so；若系统同时装了libcrypto.so和libcrypto.a，它会链接动态版——而你本意是全静态 - 更稳妥写法是把库作为显式输入项：
$(CC) main.o -L. -lmycrypto -L/opt/ssl/lib -lcrypto -lz -static -o program
为什么不能把第三方静态库“打进去”？
你可以试：ar x libcrypto.a 解包，再 ar rcs libmycrypto_full.a my_crypto.o *.o，看似“合并”了。但实际无效——因为 ar 不做符号解析，也不重写重定位信息。链接器在处理 libmycrypto_full.a 时，依然会看到对 compress 的未定义引用，且找不到该符号定义在哪一个归档成员里（除非你手动确保所有依赖的 .o 都在里面，并且顺序恰好满足依赖图）。
- 这种手工合并极易出错，且不可维护；CMake 或 autotools 都不推荐这么做
- 真正需要“封装依赖”的场景（如发布 SDK），应提供完整的
.a + 头文件 + 链接说明，而不是试图隐藏第三方依赖 - 若坚持合并，必须用
ranlib重建索引，并验证nm -s libxxx.a | grep compress是否有T（已定义）而非U（未定义）
-l，或者顺序颠倒，就卡在 undefined reference。 
