使用CodeBlocks自带MinGW通过b2编译Boost1.75时出现链接库缺失报错

这类连续出现"skipping incompatible"的链接报错，核心诱因是工具链架构不匹配、系统环境路径优先级冲突，即编译阶段调用的gcc、ld的架构版本，和搜索到的运行库文件的架构版本不一致，导致链接器判定所有匹配到的库文件无效，最终抛出cannot find的错误。

• 第一步：校验系统环境中实际生效的gcc路径
  打开新的命令提示符窗口（避免旧窗口缓存的环境变量生效），执行where gcc，查看输出的第一条路径是否为c:\codeblocks\MingW\bin\gcc.exe。如果输出存在其他路径排在前面（比如历史安装的32位MinGW、其他开发工具捆绑的MinGW），就是路径优先级冲突的直接证据——此时系统实际调用的是旧的32位版本gcc，但链接器搜索库时会遍历所有PATH路径，匹配到CodeBlocks目录下的64位.a格式库文件，就会触发"不兼容跳过"的报错。
• 第二步：校验b2实际识别的gcc配置
  进入Boost源码根目录，执行b2 toolset=gcc --debug-configuration，命令输出会打印b2检测到的gcc可执行路径、版本号。核对该路径是否与where gcc返回的第一条路径完全一致：如果b2检测到的gcc路径和预期不符，说明b2在搜索工具链时优先命中了其他位置的gcc，和后续的库搜索路径不匹配。
• 第三步：调整系统环境变量优先级
  打开系统环境变量配置页，将c:\codeblocks\MingW\bin路径移动到系统PATH列表的最顶端，确保它的优先级高于所有其他历史安装的MinGW、开发工具带的gcc路径；同时删除所有手动添加的、指向MinGW lib目录的PATH条目——gcc会根据自身可执行文件的位置自动推导对应的运行库路径，手动添加lib路径反而会打乱路径搜索顺序，触发兼容报错。
• 第四步：显式指定b2的工具链配置，避免隐式路径搜索带来的偏差
  重新进入f:\src\boost_1_75_0\tools\build目录，执行bootstrap.bat gcc重新引导生成匹配的b2可执行文件；返回源码根目录后执行编译命令时，显式指定gcc的根路径：

  b2 toolset=gcc --gcc-root="c:\codeblocks\MingW" --prefix=C:\boost release debug inlining=off debug-symbols=on --with-filesystem --with-program_options --build-type=complete install
  

  该配置会强制b2只从指定的MinGW根目录下查找gcc、ld和对应运行库，不会扫描其他路径下的不兼容文件。
• 临时验证小技巧：如果调整配置后仍有报错，可以将命令提示符的当前目录切换到c:\codeblocks\MingW\bin下，再调用完整路径的b2可执行文件执行编译。这种场景下b2会优先加载当前目录下的gcc、ld，如果编译可以正常完成，就可以100%确认是全局环境的路径优先级冲突问题。

内容的提问来源于stack exchange，提问作者chans