静态链接仅打包符号依赖的归档成员，但c++标准库易隐式引入异常/rtti/线程模块；glibc无法真正静态链接，因依赖动态机制；-static不保证c++运行时静态，需显式加-static-libstdc++和-static-libgcc；rpath优先级高于ld_library_path；ldd是验证是否真静态的唯一可靠依据。
静态链接时 libstdc++.a 和 libc.a 到底打进了什么
静态链接不是简单把所有 .o 拼一起，而是按符号依赖做裁剪。比如你只用了 std::string 和 printf，链接器不会把整个 libstdc++.a 或 libc.a 打进去，只会选其中定义了这些符号的归档成员（archive member）。
但要注意：C++ 标准库的静态链接容易隐式拉入异常、RTTI、线程支持等模块——哪怕你没显式用 std::thread 或 dynamic_cast，只要用了 STL 容器，libstdc++.a 就可能带入 libgcc_eh.a 和 libpthread.a 的部分代码。
- 用
nm -C your_binary | grep "U " | head -10查未定义符号，反推哪些库被实际引用 -
readelf -d your_binary看动态段；如果输出里没有NEEDED条目，基本确认是纯静态 - 加
-static-libstdc++ -static-libgcc才能确保 C++ 运行时也静态，光写-static不够
动态链接下 LD_LIBRARY_PATH 和 RPATH 谁优先
RPATH 优先级高于 LD_LIBRARY_PATH。可执行文件里硬编码的 RPATH（通过 -Wl,-rpath,/path/to/libs 设置）会在运行时最先被搜索，LD_LIBRARY_PATH 只在 RPATH 找不到时才起作用。
这导致一个问题：开发时设了 LD_LIBRARY_PATH 能跑通，一打包就报 libxxx.so: cannot open shared object file——因为发布包没设 RPATH，又没把 so 放进系统路径。
立即学习“C++免费学习笔记（深入）”；
- 检查当前二进制的
RPATH：用readelf -d your_binary | grep RPATH - 推荐用
-Wl,-rpath,'$ORIGIN/../lib'，$ORIGIN表示可执行文件所在目录，兼容性好 - 避免在生产环境依赖
LD_LIBRARY_PATH，它容易被覆盖或遗漏，且不适用于 setuid 程序
为什么 glibc 不能像 libstdc++ 那样静态链接
Linux 下几乎无法真正静态链接 glibc，不是编译器限制，而是设计使然：glibc 严重依赖运行时动态加载（如 getaddrinfo 调用 NSS 模块）、线程栈管理、信号处理等必须与内核交互的机制。强行用 -static 编译，会得到一个在多数系统上无法启动的二进制。
典型错误现象：Segmentation fault (core dumped) 启动即崩，或 getpwuid 返回空、DNS 解析失败——这些都不是 bug，是 glibc 静态化后功能阉割的必然结果。
- 替代方案只有两个：用
musl libc（如 Alpine Linux +clang --target=x86_64-alpine-linux-musl），或接受动态链接glibc - 用
ldd your_binary确认是否真静态：如果输出里还有libc.so.6，说明glibc没被静态进去 - 别信 “加了 -static 就万事大吉” ——
ldd是唯一可信判断依据
发布时该选静态还是动态：看部署场景，不是看“哪个更干净”
静态链接适合嵌入式、容器基础镜像、CLI 工具分发（比如用户直接下载 tar.gz 运行）；动态链接更适合长期运行的服务（如 daemon）、需频繁安全更新的场景（glibc/openssl 补丁可统一升级）。
最容易被忽略的一点：C++ ABI 兼容性。你用 GCC 12 静态链接的二进制，在 GCC 9 的系统上能跑，但若用 GCC 12 动态链接，运行时加载的 libstdc++.so.6 是系统自带的 GCC 9 版本，可能因 ABI 不兼容直接 undefined symbol: _ZTVSt14error_category 报错。
- 查目标系统
libstdc++.so.6版本：strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX - 若服务部署在受控环境（如自己维护的 CentOS 8 集群），优先动态链接 + 锁定基础镜像版本
- 若交付给客户现场部署，且无法控制其系统环境，静态链接 + musl 是更稳妥的选择
真正麻烦的从来不是“怎么连”，而是“连完之后谁负责更新、谁承担 ABI 断裂风险”。选静态还是动态，本质是在运维复杂度和发布确定性之间划一条线——这条线划在哪，得看你的交付链路卡在哪个环节。
