2. V2EX
  3. 记录两个 WIN11 下使用 mingw-make 碰到的离谱环境错误

记录两个 WIN11 下使用 mingw-make 碰到的离谱环境错误

Persona0x4343 2026-08-17 13:23 1

1. mingw32-make.exe: *** INTERNAL: readdir: Invalid argument


该错误没有找到具体的根因, 只知道解决方案:


修改环境变量, 删除或者将Microsoft Store的环境变量移动到最后


2. CreateProcess(xxx.bat, xxx.bat, ...) failed.


mingw32-make.exe 在 WIN11 上执行 gcc 命令的时候, 会将 gcc 命令封装成一个 bat 脚本执行;


当时非常迷惑的原因是:


手动调用 cmd, 并在 cmd 中执行该 bat 脚本, 执行正常, 一旦涉及到使用 Makefile, CreateProcess 这个 API 就会执行失败;


该问题的主要原因是:
WIN11 下的C:\Windows\SysWOW64下的 cmd.exe 丢了, 但是C:\Windows\System32下的 cmd 还在, AI 给出的解释是 由于 mingw32-make.exe 是 32 位的程序, 会被 windows 加载到 64 位环境下执行, 但是 64 位环境(C:\Windows\SysWOW64)下没有 cmd.exe, 所以报错. (windows 的报错友好度真的低, 忙了一晚上定位出来这个坑爹的环境问题)

最新回复 (8)
  • HankAviator 08-17 13:26
    1楼
    mingw 是个无休无尽的坑，早日迁移到 wsl 早日停止浪费生命（愿意折腾除外
  • Persona0x4343 楼主 08-17 13:29
    2楼
    @HankAviator 行业需求, 实际上是给类似使用 PLC 上位机的用户提供 c 函数编码功能....
  • ca2oh4 08-17 14:37
    3楼
    问题一是不是因为 ms-store 里面混进去了奇奇怪怪的东西
  • wnpllrzodiac 08-17 14:55
    4楼
    没苦硬吃属于是
  • qbqbqbqb 08-17 15:00
    5楼
    第一个问题的话，看一下你移动过的几个环境变量，是不是包含了其它内置 MinGW 的软件，MinGW 工具链出问题其中一个很常见的原因就是 DLL 版本不匹配，一般都是因为电脑上装了别的自带 MinGW 的软件，加了环境变量。


    第二个问题的话，除非有特殊需求，64 位系统一定要下载 64 位版本（ x86_64 ）的 MinGW 工具链，混用 32 位的容易出问题。

    如果你用的 MinGW 发行版不支持的话，可以考虑换成 winlibs 或者 mingw-w64 （注意"mingw-w64"是发行版名称，不代表一定是 64 位的，下载的时候要看一看是不是 x86_64 版本）。

    32 位和 64 位版本的 make 程序名称都是 mingw32-make.exe ，容易搞混，记得检查你实际下载到的二进制是哪个 target 的。
  • qbqbqbqb 08-17 15:07
    6楼
    补充一下，第二个问题，如果有适配别的软件的需求的话，根据你要适配的 target 来，区分清楚是 32 位版本还是 64 位版本，全部使用一致的一种，不要混用。

    确认版本要看 target 字符串里面有没有"i686"（ 32 位）或者"x86_64"（ 64 位）字样。
    不要看发行版品牌名（“mingw-w64”同时提供有 64 位和 32 位版本）
    不要看 exe 文件名（都是 mingw32-make.exe ）
  • john1024 08-17 15:53
    7楼
    毛病太多，建议 wsl 或者直接搞台 linux 机子跑编译
  • changnet 08-17 16:05
    8楼
    想起我以前迁移 linux 程序到 win ，各种 cygwin ，mingw ，一步步地改各种兼容。改到最后我全丢了，直接在代码里写#ifdef WIN 写两套代码更快，更好维护。编译脚本转为 cmake ，linux 和 win 全部用 cmake

    问题在于这个东西很难维护，尤其是一些细小的库依赖全都要自己去改。即使现在能用，后续库的升级维护很是费劲
* 帖子来源V2EX
附近帖子
返回
飞读
随机推荐