conan 2.x 老项目需显式配置 profile：compiler.version=4.9、compiler.libcxx=libstdc++，并用 [conf] 设置 tools.build:cppstd=11、tools.build:sysroot 和 tools.build:cflags/ldflags，否则无法匹配旧二进制包或解析失败。
老项目用 GCC 4.9、C++11、静态链接，Conan 默认 profile 会直接报错
profile 里必须显式声明 compiler.version 和 compiler.libcxx
Conan 2.x 不再自动推断老旧编译器细节。如果你的项目依赖 GCC 4.9 + libstdc++（不是 libstdc++11），compiler.libcxx 必须写成 libstdc++，而不是默认的 libstdc++11；否则 conan install 会找不到匹配的二进制包，甚至在解析 conanfile.py 时就失败。
-
compiler.version=4.9不能省略——即使conan profile detect检出的是 GCC 12，它也不会向下兼容 -
compiler.libcxx=libstdc++是关键：ConanCenter 上多数老版本包（如 boost/1.70.0）只提供libstdc++ABI 的二进制，写成libstdc++11就算版本对也链接失败 - 如果项目强制要求
-std=gnu++11，得在[conf]区块加：tools.build:cppstd=11，仅设compiler.cppstd=gnu11不够，后者只影响 Conan 内部逻辑
交叉或非标工具链下，CC/CXX 不能只靠 [buildenv]
老项目常带自定义 sysroot、wrapper 脚本或旧版 binutils。光在 profile 的 [buildenv] 里设 CC=/path/to/gcc-4.9 不足以让 Conan 正确传递参数——CMakeToolchain 生成时仍可能忽略 --sysroot 或 -B 路径。
- 必须配合
[conf]设置：tools.build:sysroot=/opt/staging/sysroot，否则find_package()找不到目标平台头文件 - 若 wrapper 脚本需传额外 flag（如
--no-as-needed），不要塞进CC变量，而应使用：tools.build:cflags=["--no-as-needed"]和tools.build:ldflags=["--no-as-needed"] -
tools.cmake.cmaketoolchain:user_toolchain在老项目中慎用：很多旧版 CMake（toolchain.cmake 中的set(CMAKE_SYSTEM_NAME ...)，反而导致project()报错
conan install 命令里 -s 参数优先级高于 profile
即使 profile 文件写全了，conan install . -s compiler=gcc 这种只写大类不写版本的调用，会覆盖 profile 里的 compiler.version，导致 Conan 用默认值（如 11）去查包——结果是“找不到匹配项”，但错误信息里根本不会提示你缺了 version。
- 安全写法是完整指定：
conan install . -s compiler=gcc -s compiler.version=4.9 -s compiler.libcxx=libstdc++ -s build_type=Release - 如果项目同时支持 Debug/Release，别图省事写
-s build_type=None：Conan 2.x 不允许该值，会静默 fallback 到Release，但某些老库（如 protobuf）的 debug info 构建逻辑和 release 完全不同 - 用
conan install . --lockfile=conan.lock时，确保 lockfile 本身是用同样-s参数生成的，否则版本锁定失效
老项目最麻烦的不是配置写法，而是错误信号弱——Conan 很少直接报“你的 GCC 4.9 不被支持”，而是表现为找不到包、find_package() 失败、或生成的 conan_toolchain.cmake 里 CMAKE_CXX_FLAGS 缺失 -std=gnu++11。动手前先跑一遍 conan install . -s compiler=gcc -s compiler.version=4.9 -s compiler.libcxx=libstdc++ --dry-run，看它实际选了哪些 setting 和选项。
