Conan必须显式声明settings字段，因为C++ ABI不统一：GCC、Clang、MSVC的运行时库互不兼容，且同一编译器不同版本或标准库变体（如libstdc++与libstdc++11）也存在二进制不兼容；Conan依赖settings组合生成唯一包ID，缺失关键项（如compiler、compiler.libcxx、os、arch等）会导致错误复用二进制，引发undefined reference或LNK2005等链接错误。
conanfile.py 中必须显式声明 settings，否则不同编译器生成的包会被视为同一二进制，导致链接失败或运行时崩溃。
为什么不同编译器需要独立包？
C++ ABI 不统一：GCC 的libstdc++、Clang 的 libc++、MSVC 的 MSVCP 互不兼容；即使同是 GCC，libstdc++ 和 libstdc++11 也是两个 ABI。Conan 默认按 settings 组合生成唯一包 ID，漏掉关键项就会复用错误二进制。
常见错误现象：undefined reference to `std::string::_M_create' 或 Windows 下 LNK2005 重复定义 —— 往往就是 GCC 编译的包被 MSVC 项目误链了。
settings 必须包含哪些字段？
settings 是 Conan 区分二进制兼容性的核心维度，缺一不可：
-
"os"：操作系统（"Linux"/"Windows"/"Macos"） -
"arch"：架构（"x86_64"/"armv8"） -
"compiler"：编译器名（"gcc"/"clang"/"msvc"） -
"build_type"：构建类型（"Debug"/"Release"）
此外，以下字段必须根据实际 ABI 决策显式加入：
-
"compiler.version"：GCC 9 与 12 生成的符号不兼容 -
"compiler.libcxx"：对 GCC/Clang 必填（"libstdc++"/"libstdc++11"/"libc++"） -
"compiler.runtime"：对 MSVC 必填（"dynamic"/"static"） -
"compiler.cppstd"：C++ 标准影响模板实例化（"17"/"20"）
示例完整声明：
settings = "os", "arch", "compiler", "build_type"
options = {"shared": [True, False]}
default_options = {"shared": False}
<p>def configure(self):
if self.settings.compiler == "gcc":
self.settings.compiler.libcxx = "libstdc++11"
elif self.settings.compiler == "clang":
self.settings.compiler.libcxx = "libc++"
elif self.settings.compiler == "msvc":
self.settings.compiler.runtime = "dynamic"如何验证包是否按编译器正确分离？
执行conan install . --build=missing 后，检查本地缓存路径：
- Linux + GCC 11 + libstdc++11 →
~/.conan2/p/b/hello/0.1/<em>/</em>/0/package/da39a3ee5e6b4b0d3255bfef95601890afd80709/ - Linux + Clang 16 + libc++ → 路径末尾哈希完全不同
更直接的方式是运行：
conan list * -r=local
观察输出中同一 name/version 是否对应多个 package_id，每个都带明确的 compiler=gcc 或 compiler=clang 标签。
交叉编译时 compiler 设置容易被忽略的点
交叉场景下，compiler 指的是**目标平台的编译器**，不是宿主机的。例如为 ARM Linux 构建，profile 中应设：
[settings] os=Linux arch=armv8 compiler=gcc compiler.version=11 compiler.libcxx=libstdc++11 compiler.cppstd=17
而不是宿主机的 compiler=clang。Conan 不会自动推断目标 ABI，全靠 profile 显式声明 —— 这是多数人打包后在嵌入式设备上运行崩溃的根本原因。
真正麻烦的从来不是写几行 conanfile.py，而是确认每一个 settings 字段都和你最终链接进可执行文件的那个 ABI 完全对齐。少一个，就可能让整个依赖链在某个编译器上静默失效。
