Consider builds for UCRT64?

[Berrysoft]

It seems that MSYS2 has added arch support for ucrt64, which uses Universal CRT (64-bit) as its C runtime, and provides a full toolchain. Would you consider add builds for that arch?

[rimrul]

That isn't really an architecture, but a different CRT. We allready do dynamically load some UCRT functions (like strftime) at runtime.

I went looking how linux package managers handle packages expecting alternative libc implementations and it seems like the answer for both pacman and apt seems to be they pretty much don't. So maybe a diffrent pseudo-arch is not the worst approach.

I don't think we'd want to offer actual release builds linked against UCRT in parallel to the MSVCRT builds, though. It just adds unnesscessary maintenance complexity. So from my perspective we'd want to have UCRT32 builds as well as UCRT64 builds working before we produce any official UCRT releases and then probably offer just UCRT releases.

This raises the interesting side question, what do we link the arm64 builds against? UCRT is probably our only option there, isn't it? That's probably a nice source of hard to pin-point differences between arm and intel builds.

[rimrul]

They also currently only seem to do UCRT builds for MinGW-packages, not MSYS2-packages.

Forget what I said. MSYS2-packages link against newlib.

[Berrysoft]

Well, I know it is not really an architecture, but MSYS2 (or, MinGW-packages) put ucrt64 parallel with mingw64, just like different archs. I'm asking because I'm using msys2 with git-for-windows package source, and wishing to install a package like mingw-w64-ucrt-x86_64-git.

[dscho]

@Berrysoft could you show us how such a thing would look like (preferably as a PR at git-for-windows/MINGW-packages)?

[Berrysoft]

@dscho I'm trying so, but it maybe cost some more time because MSYS2 doesn't provide enough packages for ucrt64 now.

[dscho]

@Berrysoft thank you for researching that. Could you maybe keep an eye out and let us know once enough packages are available to continue on this quest?

[Berrysoft]

@dscho OK, I'll try to PR after they're avaliable.

[Berrysoft]

I'd like to know how did you packaged cv2pdb. I didn't find the PKGBUILD in the package repo.

I also would like to know how did you packaged python2, as it is deleted from the offical msys2 repo.

[dscho]

I'd like to know how did you packaged cv2pdb. I didn't find the PKGBUILD in the package repo.

The build definition is maintained here: https://github.com/git-for-windows/build-extra/tree/main/mingw-w64-cv2pdb

I also would like to know how did you packaged python2, as it is deleted from the offical msys2 repo.

We didn't package it, we consumed it from MSYS2 when it still was offered.

[Berrysoft]

Well, I have to admit that the process trying to build git for windows in UCRT64 env is frustrating. It seems that there are many places hard coding mingw64 and mingw32, and the build process even stopped at beginning, complained missing syslog.h, which is already in compat/win32.

[Berrysoft]

I finally succeeded using cmake, with a little fix. Do you consider totally move to cmake? It will simplify a lot.

[dscho]

We do have a working CMake definition, but I can't really say what we would lose by switching to it. Neither do I see any big win... what does UCRT bring us? Is it available on every Windows version we support? Does it need to be installed manually?

[Berrysoft]

Anyway you need to ship git with a msys2 runtime, and there is UCRT support in msys2.

UCRT is a much newer C runtime than msvcrt, which is released more than 20 years ago. It contains new features, for example, Unicode support, and is continually updated by MS. However, UCRT is not available on Windows below 10 by default. It needs to be installed.

I'm asking for UCRT64 builds not for replacing the MINGW64 builds, but only asking if it can, and if it could be implemented with little effort. We now know that it could be built with cmake, and so could the CLANG64 and CLANGARM64 ones. If the cmake build system is improved to be able to replace the old build system, we could then get a lot of new types of builds, instead of only 32-bit and 64-bit (linking with msvcrt) ones.

[dscho]

There is indeed work underway to build ARM64 artifacts, but they will be hybrid. Remember, Git for Windows bundles files from ~150 separate packages. Git is but one of them. All the other packages are built using either the MSYS or the MINGW toolchains, and have currently no support for ARM64. The most obvious challenge is to get the MSYS2 runtime built for ARM64. There is currently no support to bootstrap this, therefore there is no GCC targeting MSYS/ARM64. Since the MSYS2 runtime is a close fork of the Cygwin runtime, we'd have to rely on them to support ARM64 builds. Last time I checked, there was no effort under way to that end.

That, combined with the fact that Git for Windows still needs to support Windows 7, and that Git does not need any of the features available in the UCRT (it uses direct Win32 API calls for Unicode, and does not interact with the Windows GUI in any way) makes me rather unenthusiastic to embark on what I perceive as a multi-year, multi-person project with negligible benefit, at least as far as I understand it.

[Berrysoft]

Well, no problem. I understand your choice, because there's a lot of work to do besides making the project built.