UCRT

[Peter0x44]

For those who would prefer a w64devkit with ucrt instead of msvcrt, I'm throwing up this branch.

[Peter0x44]

Huh. The build is failing in vim.

2026-05-11T01:00:53.6682653Z 697.9 /bootstrap/x86_64-w64-mingw32/bin/ld: xpm/x64/lib/libXpm.a(RdFToI.o):RdFToI.c:(.text+0xf2): undefined reference to `__imp___iob_func'
2026-05-11T01:00:53.6684224Z 697.9 /bootstrap/x86_64-w64-mingw32/bin/ld: xpm/x64/lib/libXpm.a(RdFToI.o):RdFToI.c:(.text+0x12f): undefined reference to `__imp___iob_func'

I will investigate later.

[Peter0x44]

Vim 9.0 ships prebuilt Windows XPM libraries in its source tarball under src/xpm/, including:
src/xpm/x64/lib/libXpm.a
src/xpm/x86/lib/libXpm.a
matching include files under src/xpm/*/include
Vim’s src/Make_cyg_ming.mak auto-selects these for GUI builds unless XPM=no is passed. For x64 it sets XPM = xpm/x64, then links with:
-L$(XPM)/lib -lXpm
That bundled libXpm.a was built against MSVCRT, so in a UCRT toolchain it pulls unresolved MSVCRT-era symbols like __imp___iob_func.
The XPM=no fix disables only Win32 XPM icon/sign bitmap support in gVim. Vim itself, gVim, and the rest of the GUI build still build.

For some reason, vim has a binary lib committed somewhere. I don't know why...
Disabling XPM does fix this.

[Peter0x44]

I'm so confused how this is giving errors in CI, when it builds fine on my machine.

[Peter0x44]

Somehow only half the patch was applying or something. @skeeto any ideas?
It's fixed now, but I'm wondering if there's something to do on our end in master.

[skeeto]

Hmm, in CI the patch isn't piped into patch (e.g. if the program providing input crashed we might miss it), but passed via -i. If it didn't apply fully and cleanly, patch should fail, and so the build should fail, too. Does CI not check the result of patch and we missed a write error?

[skeeto]

Ah, so you regenerated the patch to fix it. Patching is done outside a container, using the system's patch, which means, e.g. busybox-w32 if building via w64devkit. Different patch programs handle edge cases differently, and so it can work fine one place but not another. You might have changed enough to produce different results with different patch programs.

[Peter0x44]

Yeah I was very confused. It was giving errors that 32 bit support wasn't compiled in gcc, when by all accounts it should be, and when I applied the patch with busybox-w32 on my machine it built totally fine.