嵌入式设备必须使用静态库，因MCU/SoC无动态链接器，动态链接会报错；静态库将代码直接嵌入二进制，实现即烧即用，但需注意-static参数、交叉工具链匹配、头文件路径、依赖全静态化及musl替代glibc等关键细节。
嵌入式设备上必须用静态库
资源受限的 MCU 或 SoC（比如 ARM Cortex-M 系列）通常没有动态链接器，ld-linux.so 根本不存在。你编译出的可执行文件如果依赖 .so，直接报 cannot execute binary file: Exec format error 或 No such file or directory。静态库生成的 .a 会被完整塞进最终二进制里，烧录后即跑即用。
常见踩坑点：
- 没加
-static参数，GCC 默认仍可能尝试动态链接（尤其用了glibc的函数时） - 交叉编译链未指向目标平台的
ar和gcc，导致生成的.a架构不匹配（如 x86_64 的libutils.a无法用于 aarch64 固件） - 头文件路径没用
-I显式指定，编译.o阶段就失败
发布单文件 CLI 工具时优先选静态库
用户不想装一堆 .so、改 LD_LIBRARY_PATH、查 ldd 缺失项——他们只想要一个扔过去就能跑的二进制。静态库让 ./backup-tool --help 这种体验真正可靠。
关键实操细节：
- 用
gcc -static链接时，确保所有依赖（包括libz.a、libssl.a）都以静态形式存在；否则会 fallback 到动态链接并报错 -
glibc不完全支持全静态（尤其涉及 NSS 模块），必要时换musl-gcc+musl-libc静态链接更干净 - 检查结果：运行
file ./backup-tool应显示statically linked；ldd ./backup-tool应输出not a dynamic executable
算法模块封装为静态库便于团队复用
当你把图像滤波、FFT、CRC 校验等稳定模块打包成 libalgo.a，其他同事在自己的项目里只需 #include "algo.h" + gcc main.c -L. -lalgo -o main，不用碰源码、不担心 ABI 变动。
但要注意：
- 静态库本身不带版本号，
libalgo.a覆盖更新后，旧项目重编译会悄悄升级——建议配合构建脚本打时间戳或哈希后缀（如libalgo-v2.1.0-7f3a.a） - 若模块含全局变量或初始化函数（如
__attribute__((constructor))），多个静态库之间可能冲突，需显式控制初始化顺序 - 调试时符号信息默认被 strip，加
-g编译.o并保留.a，否则gdb进不去内部函数
安全敏感场景下静态链接能规避 DLL 劫持
Linux 虽无传统 DLL 劫持，但动态库路径可控性差：/etc/ld.so.preload、LD_PRELOAD、甚至 /usr/local/lib 权限松散都可能导致函数被 hook。静态库代码固化在二进制中，攻击面收窄。
不过别盲目迷信：
- 静态链接不能防逆向——
objdump -d一样能看汇编 - 若静态库用了 OpenSSL 等含已知 CVE 的旧版，漏洞仍在，只是没法热修；得靠重新编译整个二进制
- 某些系统调用（如
getaddrinfo）底层仍需 glibc 动态加载 NSS 模块，纯静态无法绕过
