静态链接时，g++默认只静态链接显式指定的库（如-static-libstdc++），而glibc禁止静态链接；全静态需换musl工具链；RPATH优先级高于LD_LIBRARY_PATH，但setuid/setgid下后者被忽略；混合链接须确保静态库置于其所依赖动态库之后。
静态链接时 libstdc++ 和 libc 怎么一起打包
静态链接不是“把所有东西全塞进一个文件”就行，g++ 默认只静态链接你显式指定的库（比如 -static-libstdc++），而 libc（即 glibc）在绝大多数 Linux 发行版上**禁止静态链接**——不是语法不支持，是 glibc 主动拒绝，因为 fork、signal、dlopen 等机制依赖运行时动态加载。
实操建议：
- 用
-static-libstdc++ -static-libgcc可以静态带入 C++ 标准库和 GCC 运行时，但libc仍走动态 - 真要全静态（比如部署到 Alpine 或无 glibc 环境），得换工具链：用
musl-gcc编译，或用clang --target=x86_64-linux-musl，配合musl-libc - 检查结果是否真静态：
ldd ./myapp输出 “not a dynamic executable” 才算成功；若显示libc.so.6，说明没生效
动态链接下 RPATH 和 LD_LIBRARY_PATH 谁优先
RPATH 是编译时写进二进制的搜索路径，优先级高于 LD_LIBRARY_PATH。但注意：如果二进制被标记为 setuid 或 setgid，LD_LIBRARY_PATH 会被内核忽略，此时只有 RPATH 和系统默认路径（/lib64, /usr/lib64）有效。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 本地跑得好，上线报
error while loading shared libraries: libxxx.so: cannot open shared object file—— 很可能是RPATH没设对，或用了相对路径（如$ORIGIN/../lib）但目录结构不匹配 - 用
patchelf --set-rpath '$ORIGIN/lib'可修复已编译二进制的RPATH，但需确保目标机器支持patchelf -
LD_LIBRARY_PATH是调试利器，但别在生产服务脚本里硬编码它——环境变量易被覆盖，且无法跨进程继承（比如 systemd 启动时不会自动传）
混合链接（部分静态、部分动态）为什么容易出 undefined reference
混合链接本质是让链接器同时处理静态归档（.a）和动态库（.so），而链接顺序和符号解析规则会立刻变复杂。典型坑是：你加了 -lfoo -lbar，但 libfoo.a 依赖 libbar.so 中的符号，而 libbar.so 在命令行里出现在 libfoo.a 后面——链接器扫到 libfoo.a 时还不知道 bar 的符号在哪，直接丢弃未满足的引用，后续再遇到 libbar.so 也救不回来。
解决关键点：
- 静态库必须放在命令行中所有它所依赖的动态库之后（即：依赖者后置）
- 用
--no-as-needed防止链接器跳过后面没立即用到的.so（默认开启--as-needed） - 查符号依赖用
nm -C libfoo.a | grep 'U '看未定义符号，再确认这些符号是否真在你链接的.so里导出（nm -D libbar.so | grep symbol_name）
CI/CD 构建镜像里选静态还是动态链接
静态链接生成单文件，适合极简容器（比如 Distroless），但代价是体积大、安全更新麻烦（每次都要重编译）、且无法利用系统级 libc 优化（如 AVX 加速的 memcpy）。动态链接则依赖基础镜像提供对应版本的 .so，但可共享库缓存、热补丁、按需加载。
实际选型看场景：
- Go/Rust 项目默认静态，C++ 没这待遇——别盲目跟风，C++ 静态链接常卡在
glibc上 - 用
ubuntu:22.04基础镜像 + 动态链接，比用alpine+ 静态链接更省心，尤其涉及 DNS、NSS、线程栈等底层行为时 - 如果必须静态，优先考虑
manylinux兼容性规范（用auditwheel检查），而不是自己手搓-static
最常被忽略的一点：C++ ABI 兼容性。哪怕都用 libstdc++.so.6，GCC 7 编译的二进制在 GCC 12 系统上可能因 std::string 内存布局变化而崩溃——动态链接不等于安全，ABI 版本必须对齐。
