静态链接可彻底消除依赖，但需显式添加 -static-libgcc 和 -static-libstdc++；动态链接易因库缺失或版本不匹配崩溃；桩库可在无真实库环境下满足符号引用，但C++模板等无法桩化。
静态链接是最直接、最可控的减少依赖方式，但不是唯一解法。动态链接虽灵活，却容易在目标设备上因库缺失或版本不匹配而崩溃；静态链接把所有依赖打包进二进制，部署时只需一个文件，无需担心 libstdc++.so.6 或 libc.so.6 找不到。
用 -static 强制静态链接 C 和 C++ 运行时
多数人只加 -static，但 GCC 默认仍可能动态链接 C++ 标准库。必须显式禁用动态链接行为：
- 加
-static同时确保工具链支持完整静态链接（部分精简版arm-linux-gnueabihf-gcc会忽略-static-libstdc++） - 显式带上
-static-libgcc -static-libstdc++，否则std::string、异常处理等仍可能触发动态符号 - 验证是否真静态：运行
file your_binary，输出含statically linked；再用arm-linux-gnueabihf-readelf -d your_binary | grep NEEDED，结果应为空
避免隐式动态依赖：慎用 dlopen / RTLD_NOW
即使你没写 dlopen，某些第三方库（如 libcurl、openssl）默认启用运行时加载机制，会悄悄引入 libdl.so 依赖。这不是编译期决定的，而是运行时行为：
- 交叉编译这些库时，务必传
--disable-shared --enable-static，并确认configure输出中checking for dlopen... no - 链接时加
-Wl,-z,now -Wl,-z,relro可强制符号解析提前，暴露潜在的未满足动态引用 - 若必须用
dlopen，需在目标设备上部署对应.so，此时已不属于“减少依赖”范畴，而是主动管理依赖
桩库（Stub Library）替代动态库接口，保留运行时灵活性
当目标设备上已有稳定版本的 libfoo.so，但你不想在构建机上放真实库文件——比如 CI 环境无法访问板端 SDK ——桩库就是折中方案：
- 桩库只需导出函数签名（
extern "C"声明），实现全空或返回错误码，大小通常几百字节 - 链接时用
-L/path/to/stub -lfoo，生成的可执行文件仍含NEEDED libfoo.so，但符号解析由桩库满足 - 运行时靠目标设备的
ld-linux.so加载真实libfoo.so，只要 ABI 兼容（函数名、参数、调用约定一致），就能无缝替换 - 注意：C++ 模板、内联函数、RTTI 不能桩化，这类符号必须在桩库中提供完整定义或彻底规避
真正难的不是让程序“跑起来”，而是让它在不同批次刷写的固件上持续可用。静态链接解决部署问题，桩库解决协作与复用问题，而漏掉 -static-libstdc++ 或误信“已禁用 shared”的第三方库配置，是现场最常导致 Segmentation fault (core dumped) 的隐形原因。
