conan不管理glibc、musl、libstdc++等系统库，仅处理显式声明的第三方包；需通过profile明确指定compiler.libcxx和os.libc以匹配实际运行时环境，否则将导致abi错配或链接失败。
Conan不管理glibc、musl、libstdc++这类系统库
Conan默认不触碰系统级运行时库——它只管你显式声明的第三方包（如 openssl/3.1.3、fmt/10.2.1），而 glibc、musl、libstdc++、libgcc 这些由操作系统或工具链提供，Conan 既不下载也不替换。你真正要做的，是让 Conan 知道“当前环境用的是哪套系统库”，否则它可能错配 ABI 或链接失败。
Profile里必须明确指定libc和libcxx
交叉编译或跨发行版构建时，profile 文件里漏掉 compiler.libcxx 或 os.libc 是最常见崩溃点。比如在 ARM64 Linux 上用 glibc 2.35，但 profile 写成 compiler.libcxx=libc++，就会导致链接时找不到 std::string 符号。
-
compiler.libcxx要匹配你实际链接的 C++ 标准库：对 GCC 多数是libstdc++或libstdc++11；对 Clang + glibc 可能是libstdc++11，用 musl 则只能选libstdc++（musl 不带 libc++） -
os.libc在 Conan 2.x 中仅对 musl 有效（设为musl），glibc 场景下靠os+os.version隐式约束，例如os=Linux+os.version=2.35 - 若目标系统是 Alpine（musl），profile 必须含
os.libc=musl，且所有依赖（包括openssl）得用 musl 编译的二进制，否则conan install会报Missing prebuilt package
系统库路径冲突：sysroot不是可选项，是必填项
当你面对嵌入式或容器化构建（如基于 debian:12-slim 或 alpine:3.20 的 CI 环境），不能依赖宿主机的 /usr/include 或 /lib/x86_64-linux-gnu。Conan 必须通过 conf 段落把 sysroot 塞给底层构建系统：
- 在 profile 中加：
[conf] tools.build:sysroot=/opt/sysroots/debian12
- 这会让
CMakeToolchain自动生成-DCMAKE_SYSROOT=...，并确保find_package(OpenSSL)查找头文件和库时不误入宿主机路径 - 如果没设 sysroot，而你的交叉工具链前缀是
aarch64-linux-gnu-，Conan 可能仍去宿主机/usr/lib找libssl.so，结果链接出 x86_64 版本，运行时报cannot execute binary file
OpenSSL这类“半系统库”要特别小心
openssl 在很多发行版里既是用户态依赖，又深度耦合系统 crypto 模块（如 libcrypto.so.3 的 soname、FIPS 模块路径、CA 证书位置）。Conan 安装的 openssl/3.1.3 不会覆盖系统 /etc/ssl/certs，但它生成的 libssl.so 默认不加载系统插件目录。这意味着：
- 如果你的应用调用
ENGINE_load_builtin_engines()，得手动在运行时OPENSSL_MODULES=/usr/lib/openssl-modules，Conan 包不负责这个 - 静态链接
libcrypto.a后，SSL_CTX_new()可能因缺少providers初始化而失败，需在代码里加OSSL_PROVIDER_try_load(NULL, "legacy", 1) - Conan 的
openssl包默认关闭fips选项；若目标环境强制 FIPS，必须显式写-o openssl:fips=True并确认该二进制已在对应 profile 下构建过
系统库不是“看不见就等于不存在”。它们藏在 ABI 层、链接器搜索路径、运行时 dlopen 行为里——Conan 能帮你隔离第三方依赖，但不会替你绕过 Linux 的基础契约。
