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.

[anzz1]

You are actually trying to push to master instead of a separate branch, although idk if its possible to make a PR into a branch that doesn't exist yet?

In any case, the word of advice is to steer way clear of UCRT. In fact one of the big reasons to use minGW in the first place is that you can cleanly stay off UCRT without resorting to tricks compared to MSVC that tries its hardest to push it on you.

[Peter0x44]

Just because the PR is open doesn't mean I'm going to merge it. I definitely wouldn't merge this without also being able to offer an msvcrt variant. This is purely experimental.

Ucrt is better in some ways, worse in others. Apparently it's required for sanitizers to work.

[Peter0x44]

I just want to keep it researched and know what is involved in case it becomes useful later. I have several PRs open that I don't intend to merge.

[Peter0x44]

Turns out, for gcc 14, Pali added an -mcrtdll option.
https://chatgpt.com/s/t_6a77a95a3c008191912baa1c4a6f86bf

So I would get that working so it can be selected, if I was going to merge this. No plans to do it soon.

[Peter0x44]

https://chatgpt.com/s/t_6a77ac220fc88191be2b9b28b54d6a6f

[skeeto]

I appreciate these research branches, @Peter0x44.

[skeeto]

In your shared session which model was that and what effort? It's a little frustrating the shared view doesn't indicate it.

[Peter0x44]

Gpt 5.6 sol extra high