c++oding="utf-8" ?>
conan 不管理 libstdc++ 但能隔离 abi：通过 profile 显式声明 compiler.libcxx（libstdc++ 或 libstdc++11）确保所有依赖统一 c++ 标准库 abi；cmake 需用 cmaketoolchain 正确链接对应 libstdc++.so.6，否则运行时仍报 glibcxx 版本错误。
Conan 不直接管理 libstdc++，但能隔离它
Conan 本身不下载、不替换系统级的 libstdc++.so.6，也不修改 GLIBCXX_* 符号版本。它的作用是：让「你用的库」和「你用的 libstdc++」在构建时就对齐，避免运行时混用不同 ABI 的 C++ 标准库。一旦你在 Profile 里声明了 compiler.libcxx=libstdc++11 或 libstdc++，Conan 就会确保所有依赖（比如 openssl、fmt）都用同一套 ABI 编译，而不是靠系统默认“碰运气”。
Profile 必须显式声明 libcxx 和 ABI
很多用户漏掉这步，结果 Conan 下载的包仍用旧 ABI，和你的主程序不兼容。关键不是编译器版本，而是 compiler.libcxx 和 _GLIBCXX_USE_CXX11_ABI 是否一致：
-
compiler.libcxx=libstdc++→ GCC 4.x / 旧 ABI（std::string是 COW 实现） -
compiler.libcxx=libstdc++11→ GCC 5+ 默认 ABI（std::string是 SSO 实现），对应_GLIBCXX_USE_CXX11_ABI=1 - 若你用 GCC 12 但必须兼容旧系统，可强制设
compiler.libcxx=libstdc+++compiler.cppstd=17+conf:tools.build:cxxflags=["-D_GLIBCXX_USE_CXX11_ABI=0"]
生成器要配合 CMake 正确注入 stdlib 路径
即使 Conan 下载了正确 ABI 的依赖，CMake 若仍链接系统默认 libstdc++.so.6（比如 Ubuntu 18.04 自带的 3.4.25），运行时还是会报 GLIBCXX_3.4.26 not found。解决办法是让 CMake 显式链接 Conan 提供的工具链中指定的 libstdc++：
- 用
CMakeToolchain生成器时，在conanfile.py中启用：toolchain = CMakeToolchain(self)，它会自动写入set(CMAKE_CXX_STANDARD_LIBRARIES "... -lstdc++")并设置CMAKE_CXX_FLAGS - 手动补救：在
CMakeLists.txt末尾加set(CMAKE_CXX_STANDARD_LIBRARIES "${CONAN_LIBS_STD}")（需 Conan 2.1+ 提供该变量） - 验证是否生效：编译后执行
readelf -d your_executable | grep NEEDED，确认只出现一次libstdc++.so.6，且没混入其他路径
交叉编译时 libcxx 错配最危险
嵌入式场景下，宿主机（x86_64 Ubuntu）和目标机（aarch64 Linux）的 libstdc++.so.6 版本天然不同。Conan 不会帮你把宿主机的 libstdc++ 复制过去——它只保证你用的 zlib、curl 等第三方库，是用目标机 Profile 指定的 compiler.libcxx 编译出来的。真正运行时缺符号，往往是因为你忘了在 target sysroot 里放对版本的 libstdc++.so.6，或者没在 LD_LIBRARY_PATH 或 RPATH 里指向它。这时候 Conan 只负责“不拖后腿”，不负责“兜底运行”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
