直接静态链接 libstdc++ 最稳妥，但必须搭配 -static-libgcc、编译器 ABI 控制及目标系统基线约束；仅靠 LD_LIBRARY_PATH 或软链接易致符号版本错位、混合 ABI 崩溃和系统污染。
直接静态链接 libstdc++ 是最稳妥的方案，但必须配合编译器 ABI 控制和目标系统基线约束，否则会引入隐性冲突或运行时崩溃。
为什么不能只靠 LD_LIBRARY_PATH 或软链接
很多开发者第一反应是把高版本 libstdc++.so.6 拷过去、加 LD_LIBRARY_PATH，或者用 ln -sf 覆盖系统库。这在测试机上常能“跑起来”，但实际部署后容易出三类问题：
- 符号版本错位：你拷的
libstdc++.so.6里有CXXABI_1.3.15，但目标机器的glibc或内核不支持该 ABI 所依赖的底层 syscall 行为（比如某些 C++17 并发原语） - 混合 ABI 崩溃：程序一部分用了静态链接的旧 ABI，另一部分动态加载了新 ABI 的第三方插件（如 OpenCV dnn 模块），
std::string或std::shared_ptr的内存布局不一致，free()释放错堆 - 系统污染风险：覆盖或强制插入
libstdc++可能导致apt、systemd等系统组件异常，尤其在 CentOS/RHEL 类发行版上
-static-libstdc++ 必须搭配 -static-libgcc
单独加 -static-libstdc++ 很危险：C++ 异常处理、RTTI、线程局部存储（TLS）等机制依赖 libgcc_s.so 提供的运行时支持。若 libgcc 仍动态链接，而 libstdc++ 静态进去，两者 ABI 不匹配会导致 std::terminate 无法正确调用、栈展开失败等静默崩溃。
正确做法是成对使用：
立即学习“C++免费学习笔记（深入）”；
g++ -o myapp main.cpp -lstdc++ -lgcc -static-libstdc++ -static-libgcc
注意：-lgcc 必须显式写在命令行中（即使没直接调用 GCC 内建函数），否则链接器可能跳过 libgcc 相关符号，导致 _Unwind_Resume 找不到。
构建环境必须比目标系统更老
静态链接解决的是“库存在与否”的问题，但不解决“系统能力是否足够”的问题。例如：
- 在 Ubuntu 24.04（glibc 2.39）上编译并静态链接
libstdc++，生成的二进制仍可能依赖GLIBC_2.34新增的memrchr符号，无法在 CentOS 7（glibc 2.17）上运行 - 使用
std::filesystem会隐式调用openat2系统调用，在内核 ENOSYS
所以构建机器应选最低目标发行版（如 CentOS 7 或 manylinux2014 镜像），而非本地开发机。Meson 官方推荐的 manylinux2014_x86_64 容器就是为此设计——它锁定了 glibc 2.17、GCC 5.3、内核 3.10 的组合，确保 ABI 兼容下限。
rpath 和 patchelf 是动态方案的底线
如果必须保留动态链接（比如因许可证限制不能静态链接某些库），那就得让程序自己带路，而不是依赖系统路径：
- 编译时加
-Wl,-rpath='$ORIGIN/../lib'，让可执行文件记住“我的库就在我旁边” - 用
patchelf --set-rpath '$ORIGIN/lib' myapp重写已存在的二进制（比编译时控制更灵活） - 打包时把所有依赖 so 放进
./lib/，并确保它们之间无版本冲突（ldd -r检查未定义符号，objdump -T查看导出符号版本）
特别注意 OpenCV 这类库：它的 libopencv_dnn.so 可能悄悄依赖 libopenvino.so，而后者又依赖另一套 libstdc++ ——这种嵌套动态依赖最容易漏掉，必须用 ldd 递归扫到底层。
真正麻烦的不是“怎么打包”，而是“怎么定义兼容边界”。一旦你决定支持某台 2014 年出厂的 CentOS 7 物理机，就得接受它没有 AVX2、没有 std::optional、甚至没有完整的 C++14 语法支持——这些限制会倒逼你从 CMakeLists.txt 第一行就开始做取舍。
