glibcxx版本缺失本质是程序依赖的c++标准库符号版本高于系统所装libstdc++.so.6提供的版本；需通过升级gcc、静态链接或设置ld_library_path解决，而非简单拷贝.so文件。
Conan 本身不解决运行库差异，它只确保你声明的 ABI 约束被严格执行——漏掉 compiler.libcxx 或 compiler.runtime，编译能过，链接或运行时必崩。
为什么 compiler.libcxx 必须显式指定
Linux 上 glibc 和 libstdc++/libc++ 不是“默认一致”的：同一份 conan install 命令，若没写 compiler.libcxx=libstdc++11，Conan 可能复用旧二进制（比如 libstdc++ 旧 ABI），而你的项目用了 std::string_view 或 std::filesystem，就会在 undefined reference 或 GLIBCXX_3.4.30 not found 上栽跟头。
- GCC 11+ 默认用
libstdc++11，但 Conan 不自动推断——必须写进 profile 或命令行 - Clang + libc++ 场景下，
compiler.libcxx=libc++缺一不可，否则 CMake 找不到libc++.so对应的xxxConfig.cmake - Windows MSVC 的
compiler.runtime（MD/MT）必须和你的项目设置严格一致，混用会导致LNK2005或堆崩溃
conan install 命令里漏掉 runtime 设置的典型错误
执行 conan install .. -s compiler=gcc -s compiler.version=12 -s build_type=Release 看似完整，但缺了 -s compiler.libcxx=libstdc++11。结果：
- OpenSSL 包可能用旧版
libstdc++编译，而你的主工程用 C++17 新 ABI ——std::string内存布局不兼容 - CMake 链接时看似成功，但运行时报
std::length_error或直接段错误 - 用
readelf -d your_binary | grep NEEDED能看到混着libstdc++.so.6和libstdc++.so.6.0.30，这就是 ABI 错配信号
Profile 文件里怎么写才不踩 runtime 坑
别信“系统默认”，profile 必须把运行库决策固化下来。例如 profiles/linux-gcc12-cxx17 应含：
[settings]
os=Linux
arch=x86_64
compiler=gcc
compiler.version=12
compiler.libcxx=libstdc++11
compiler.cppstd=17
build_type=Release
[conf]
tools.build:compiler_executables={"c": "gcc-12", "cpp": "g++-12"}
-
compiler.libcxx是强制项，不是可选项；libstdc++和libstdc++11是两个不同 ABI 的库 - Windows 上必须加
compiler.runtime=MD（动态）或MT（静态），且和 CMake 的CMAKE_MSVC_RUNTIME_LIBRARY保持一致 - 交叉编译时，
tools.build:sysroot路径下的usr/lib必须包含你声明的libcxx版本，否则 Conan 会静默 fallback 到主机环境
最常被忽略的一点：Conan 的 profile 是“构建时契约”，不是“运行时担保”。它只管编译链路对齐，不管目标机器上有没有对应版本的 libstdc++.so.6.0.30——那得靠你部署时带全依赖，或用 conan install --deploy 拉出运行时库。ABI 错配不会报错在 conan install 阶段，而是在 dlopen 或第一次调用 STL 函数时才暴露。
