Windows下MSYS2 GCC编译Boost 1.87.0的架构识别与编译错误问题

问题根源 #

核心问题是在Windows原生命令行（CMD/PowerShell）下运行MSYS2的GCC，导致Boost.Build无法正确解析编译器输出的CPU架构、ABI等关键特性信息，进而出现asm_sources匹配失败、特性标记全为"no"的错误，最终引发依赖缺失导致编译失败。MSYS2的GCC需要在自身的shell环境中运行，才能保证路径解析、编译器输出格式符合Boost.Build的预期。

修复步骤 #

1. 启动正确的MSYS2 Shell
   打开MSYS2安装目录下的ucrt64.exe（对应你使用的UCRT64环境），进入Boost源码根目录（Windows路径C:\boost_1_87_0对应MSYS2中的POSIX路径/c/boost_1_87_0）。

2. 修正或移除user-config.jam配置

   • 若保留user-config.jam，将路径改为MSYS2的POSIX格式：

     using gcc : : /ucrt64/bin/g++.exe ;
     

   • 更简便的方式是直接删除user-config.jam：MSYS2的UCRT64环境已将GCC加入PATH，Boost.Build会自动检测到正确的编译器，无需手动配置。

3. 重新执行编译命令
   在MSYS2 UCRT64 Shell中运行以下命令（使用POSIX风格的命令格式）：

   ./b2 toolset=gcc install -q --build-type=complete --without-python -j16 -sNO_BZIP2=1 -d+4
   

4. 验证环境依赖
   确保UCRT64环境已安装基础编译工具：

   pacman -S base-devel gcc make
   

额外说明 #

• Boost.Context库依赖CPU架构和ABI信息选择对应汇编源文件，特性检测失败时，Build系统无法找到匹配的汇编代码，就会抛出No best alternative for asm_sources错误。
• MSYS2的GCC在Windows原生环境中运行时，输出的架构标识、路径格式等与MSYS2 Shell环境下不同，导致Boost.Build的特性检测逻辑全部失效，出现BOOST_ARCH_X86等标记为"no"的异常。

内容的提问来源于stack exchange，提问作者Tomáš Zato