Conan 2.x中[buildenv]配置CC需配合tools.build:compiler_executables才生效，否则被静默忽略；profile不可混用[env]与[buildenv]，OpenSSL等包还需显式传入环境变量或使用CMakeToolchain指定sysroot与target。

编译器路径没生效导致 CC 环境变量被忽略

Conan 2.x 中，[buildenv] 是控制构建时编译器的关键配置段，但很多人误以为只要写了 CC=aarch64-linux-gnu-gcc 就一定生效。实际常见错误是 profile 文件里混用了 [env]（运行时环境）和 [buildenv]（构建时环境），或者没配 tools.build:compiler_executables。结果就是 Conan 还是调用本机 gcc，报错里完全看不到 aarch64 字样。

检查方法：执行 conan install . -pr=myprofile --build=missing -v，在 verbose 日志里搜 Running command:，看真正执行的命令是不是你期望的交叉编译器。

• [buildenv] 必须配合 tools.build:compiler_executables 使用，否则会被静默忽略
• profile 中不能同时存在 [env] 和 [buildenv] 对同一变量的定义，后者优先但不覆盖前者逻辑
• 如果用 conanfile.py 手动 set self.conf["tools.build:compiler_executables"]，优先级高于 profile

openssl 编译时报 HINSTANCE、LoadLibraryA 未声明

这是典型的 Windows 下 MinGW 编译 OpenSSL 时头文件/宏定义错乱的表现——不是代码问题，而是 Conan 没把编译器类型正确透传给 OpenSSL 的 configure 脚本。OpenSSL 会根据 CC 可执行文件名自动判断平台，但如果你用的是 msys2 自带的 gcc（路径含 msys 或 clang），它会误判为 MSVC 环境，却没引入 windows.h，于是 HINSTANCE 这类 Win32 类型直接报错。

解决核心就一条：确保 CC 指向明确标有 mingw 的编译器，比如 x86_64-w64-mingw32-gcc，而不是 /usr/bin/gcc。

• MinGW 编译必须用 conan install -e CC="x86_64-w64-mingw32-gcc" -e CXX="x86_64-w64-mingw32-g++" 显式传入
• 不能依赖 profile 里的 [buildenv]，因为 OpenSSL 的 configure 脚本不读 Conan 的 buildenv
• 如果用 CMake 构建 OpenSSL（部分 conan-center 包支持），则要额外加 -DCMAKE_SYSTEM_NAME=Windows

交叉编译时链接失败，提示找不到 libc 或 libm

这不是库缺失，而是工具链路径没对上。比如用 aarch64-linux-gnu-gcc 编译，但没指定 --sysroot 或 CONAN_CMAKE_SYSROOT，链接器就会去本机 /usr/lib 找 libc.so，自然失败。典型报错是：cannot find -lc 或 undefined reference to `memcpy'。

Conan 2.31.2

Conan 2.31.2 官方历史源码包，适合复现依赖解析、CMake 配置、二进制包兼容性和跨平台构建环境。

下载

Conan 本身不自动推导 sysroot，得靠你填。

• profile 中加 tools.build:sysroot=/path/to/aarch64-linux-gnu/sysroot
• 或通过 conan install -e CONAN_CMAKE_SYSROOT=/path/... 传入
• 若用 CMakeToolchain，需在 conanfile.py 里显式设置 self.conf["tools.cmake.cmaketoolchain:system_path"] = "/path"
• 注意：sysroot 路径末尾不能带 /usr，CMakeToolchain 会自动拼接

Conan 2.30+ 报 AttributeError: 'CMake' object has no attribute 'definitions'

这不是编译器配置错，但常和编译器切换一起出现——因为升级 Conan 后旧写法失效。Conan 2.x 的 CMake 类不再暴露 definitions 属性，所有 CMake 变量必须走 cmake.configure(variables={...}) 或 toolchain 文件注入。

比如原来这么写：

cmake.definitions["CMAKE_C_COMPILER"] = "aarch64-linux-gnu-gcc"

现在必须改成：

cmake.configure(variables={"CMAKE_C_COMPILER": "aarch64-linux-gnu-gcc"})

• 旧版 cmake.definitions 在 Conan 2.0 已弃用，2.30+ 直接删除
• 如果用了 CMakeToolchain generator，变量应统一放在 toolchain 配置里，而非 configure() 中
• 交叉编译场景下，CMAKE_SYSTEM_NAME、CMAKE_SYSTEM_PROCESSOR 这类变量必须显式设，不能依赖编译器名自动推断

交叉编译最麻烦的从来不是命令写不对，而是错误信息根本没提“编译器”三个字——它可能表现为链接失败、头文件找不到、甚至某个 .c 文件里几百行 Win32 类型报错。这时候得倒着查：先确认 CC 真的进了构建命令，再确认 sysroot 和 target 是否匹配，最后才轮到源码逻辑。