Wrong libucrt.lib is installed

[momo5502]

Hey, I'm encountering the following error.

Compiling/executing the following C/C++ line using a regular SDK (and static runtime using /MT) on my windows machine yields a non-null pointer as a result:
setlocale(LC_ALL, ".UTF-8")

When ompiling/executing that line using the xwin SDK, it fails and returns a nullptr.

I'm using the following commandline to setup the SDK:

xwin --accept-license --include-atl --arch x86 --sdk-version 10.0.22621 splat --include-debug-libs --output /xwin

Looking at the libucrt.lib that got downloaded, I can see it has about 60mb.

I have installed the exact same Windows SDK on my native Windows machine and the libucrt.lib seems to be around 38mb.

I think the one that gets installed through xwin is outdated. As UTF-8 support got introduced with SDK 10.0.17134, the version that gets installed through xwin must be before that one. Even though I specified 10.0.22621. Specifying no SDK version at all also installs the wrong lib.

Manually exchanging it through the lib from my windows machine causes the setlocale test to work. So I assume xwin either downloads an outdated lib or an entirely outdated SDK.

[Jake-Shadle]

Well that's weird. I'll look at it over the weekend.

[redactedontop]

Hey, what's up with this issue?!

[Jake-Shadle]

I tried to debug it a while back but as far as I could tell no cabinet that is downloadable from the set that is specified in the manifest contains a UCRT with the same hash, and I wasn't super motivated to keep digging at the time because newer UCRT versions are irrelevant for me. So if someone is motivated they can point out the cabinet url for a particular SDK version that contains the UCRT and I can either figure it out from there or someone can open a PR.

[redactedontop]

So, we're still stuck with the old CRT? Although, we should all just use VC-LTL...

[Jake-Shadle]

Yes.

[redactedontop]

Does this only happen with --include-debug-libs?