Windows下编译Stockfish程序Make执行失败报错问题排查

原生CMD环境（Chocolatey安装make）报错分析 #

该环境下编译失败的核心原因是：Chocolatey分发的Win32移植版make在找不到POSIX shell环境时，会默认调用Windows cmd解释器执行Makefile内的指令，但Stockfish的Makefile完全基于类Unix（Linux/macOS）环境编写，大量依赖Unix专属命令与POSIX shell语法，和cmd的批处理逻辑完全不兼容，因此在编译前置检测阶段就会直接中断。
各报错点的具体含义：

• 重复出现的process_begin: CreateProcess(NULL, uname -s, ...) failed：uname是Unix系统下用于查询内核版本、硬件架构的命令，cmd原生不存在该命令，进程创建直接失败
• 'grep' is not recognized as an internal or external command：grep是Unix环境下的文本搜索工具，cmd无内置对应实现
• curl was unexpected at this time、shasum was unexpected at this time、-f was unexpected at this time：Makefile中用于神经网络资源下载、校验、文件判断的逻辑使用POSIX shell语法编写，cmd无法解析该类语法，即使提前安装了curl、shasum等命令也会因语法不兼容报错
  手动指定架构、编译器参数无法解决问题的原因：参数生效阶段在环境检测、依赖资源准备步骤之后，Makefile还没走到实际编译流程就已经中断。

Cygwin环境编译报错分析 #

该环境下编译失败的核心原因是工具链格式不匹配：当前安装的Cygwin版GCC与汇编器的目标文件格式配置不一致，GCC输出了类Unix ELF格式的汇编伪指令，但汇编器按Windows PE格式规则解析代码，触发语法错误，后续的链接时优化（LTO）失败是汇编步骤中断后的连锁反应。
各报错点的具体含义：

• .type pseudo-op used outside of .def/.endef: ignored、Error: junk at end of line, first unrecognized character is 'g'：.type是ELF格式汇编中用于标记符号类型的伪指令，Windows PE格式汇编使用.def/.endef块完成符号定义，两者语法不兼容直接触发解析错误
• lto-wrapper failed、ld returned 1 exit status：汇编阶段生成目标文件失败，LTO包装进程无法拿到合法的中间文件，链接器最终报错退出

可行修复方案 #

按稳定性从高到低排序：

• 优先使用WSL2编译（零兼容问题，和官方推荐的Linux编译环境完全一致）
  1. 启用WSL2并安装Ubuntu发行版，进入WSL终端后执行以下命令安装编译依赖：

     sudo apt update && sudo apt install -y make g++ curl
     

  2. 切换到Stockfish源码的src目录，执行编译命令：

     make -j$(nproc) build ARCH=x86-64-modern
     

  3. 编译完成后即可在当前目录拿到可执行文件，全程不会出现环境兼容问题。
• 使用MSYS2替代Cygwin/Chocolatey的原生编译环境
  1. 安装MSYS2后打开MINGW64终端，执行以下命令安装编译依赖：

     pacman -Syu --noconfirm
     pacman -S --noconfirm make mingw-w64-x86_64-gcc curl
     

  2. 切换到源码src目录，执行和WSL环境相同的编译命令即可，MSYS2的MinGW工具链专门针对Windows原生编译做了适配，不会出现Cygwin环境下的汇编格式不兼容问题。
• 修复现有Cygwin环境（不推荐，兼容问题较多）
  1. 卸载Cygwin原生的gcc、binutils包，改装mingw64-x86_64-gcc、mingw64-x86_64-binutils的MinGW目标版本工具链
  2. 编译时添加两个参数规避兼容问题：make build ARCH=x86-64-modern COMP=mingw lto=no，其中lto=no用于关闭链接时优化，跳过容易报错的LTO环节。

注意：不要在原生cmd/PowerShell环境下直接用移植版make编译面向Unix环境开发的大型C/C++项目，这类项目的Makefile几乎都不会适配cmd的批处理语法，强行补全移植命令的时间成本远高于直接切换到WSL/MSYS2环境的成本。

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