Any plans for an ARM64-compatible release

[andyraf]

Are there any plans to support an ARM64-compatible release of Git for Windows?

[PhilipOakley]

My ignorance here, but is Windows on ARM64?

This maybe an 'upstream' question to see if the new Azure CI capability could build and test for ARM (and maybe the Rasp pi? he says with ulterior motives...)

[dscho]

Are there any plans to support an ARM64-compatible release of Git for Windows?

I looked into it, and the main issue is the lack of an ARM64 version of MSYS2. There does seem to exist an ARM64 version (at least a preliminary one) of Cygwin (on which MSYS2 is based), so there is hope.

However, I would like to encourage everybody who is interested in ARM64 support to chip in some work, as there is plenty to do before we will have a working Git for Windows on ARM64. Like, highly encourage.

I talk about MSYS2 because we need this for the parts of Git that are still implemented as Unix shell and Perl scripts (git bisect and git submodule are probably the two most prominent ones).

In the short run, if you should try to build Git for Windows yourself, in Visual Studio, by cloning this repository and checking out vs/master. Last time I checked, this failed to build the prerequisites, apparently vcpkg did not support building OpenSSL for ARM64 back then (this might have changed, see https://github.com/microsoft/vcpkg/releases for more details).

[ssimontis]

It's my understanding that you can only natively build ARM64 apps on Windows if they are based off of UWP. Otherwise, there is an x86 emulator for running Win32 applications, and Microsoft announced in November that they were working on an x64 emulator for Windows applications. I think we would need to wait until Microsoft makes x64 emulation generally available to approach this. If there's any preliminary work I can do in the mean time that would help out, please feel free to let me know and I will be happy to see what I can do.

[rhuijben]

This is no longer the case. I just build the first Subversion on Windows on ARM64 build, using some patches that should be in the released versions soon.

[manbearian]

@dscho I'm interested in helping with bringing Git for Windows to ARM64. Locally i was able to get the vckpg dependencies built for ARM64 with only a tiny bit of hacking. The result of my efforts is a an ARM64 git.exe binary that at least dumps the help message successfully on my ARM laptop (i haven't tried anything else yet). Would you like to chat either here or offline about what you see as the full list of work that might be required beyond this?

ian Bearman
Principal Software Engineering Manager
Microsoft Visual C++ Team: Optimization & Code Generation
/* Making your code faster, smaller, smarter! */

[dscho]

That sounds amazing! Let's chat here, okay?

One of the biggest obstacles to getting Git to work on ARM is the lack of a Bash. But many things already work without a Bash...

So we could aim first for building a slightly incomplete Git for Windows (ARM64 edition) using the Visual C build.

What was that hackery you needed? Patches to vcpkg?

[manbearian]

I can create a PR for my changes, but i'm not sure the process for this. The changes are all in the 'git' source tree. Is there doc/contributors guide that covers this?

In the meantime, here's an outline of what i did based on SDK-64:

• project/sln changes (through perl script)
  • upgrade project to more recent VS (required to get ARM64 compilers, i picked latest, v142).
  • add ARM64 build configurations to projects/solution
  • added an item to the vcxprojs for VCPKGArch to be set correctly for ARM64
• source changes
  • update compat/bswap.h
• vcpkg changes
  • update compat/vcbuild/vcpg_install.bat to install both x64 and ARM64 packages
  • manually run the vcpkg_install script to install ARM64 packages

After these changes, building the git.sln for ARM64 "just works". I copied over to my ARM64 device and i have some very basic functionality working (i.e. the logo and help message). I dropped the binary into a folder layout matching an installed version and things got a bit better, but authentication for a fetch didn't work (missing DLLs i believe) and git checkout doesn't work if there are any new files (i didn't look further into this last week).

Is there a top-down view i can get of dependencies? That might be better than stabbing tin the dark looking for missing pieces. Additionally, i couldn't find documentation on building the installer, which i thought might give me a clue as to what binaries i need to look for.

[rimrul]

The documentation for building an installer is at https://github.com/git-for-windows/git/wiki/Making-an-installer

[manbearian]

Btw, i've tried to push my local changes to the git repo, but its not working for me...

C:\git-sdk-64\usr\src\git>"C:\Program Files\Git\cmd\git.exe" push --set-upstream origin initialArm64 remote: Permission to git-for-windows/git.git denied to manbearian. fatal: unable to access 'https://github.com/git-for-windows/git/': The requested URL returned error: 403
Ideas?

[rimrul]

You don't have push access to git-for-windows/git (very few people do). Click "Fork" near the top to create a copy on your github account, push there, then create a pull request.

[manbearian]

I'm making steady progress by mixing x86 binaries (from x86 install of Git for Windows) and the ARM64 binaries i built. I'm blocked on a few things right now and any help on these is appreciated:

1. trying to make progress on clone: i can now clone from a repo on github (e.g. my copy of git sources), however i cannot clone something in Azure DevOps. Likely related to authentication, but i'm seeing this message:

Cloning into 'c:\msvc1'...
fatal: Unsupported SSL backend 'openssl'. Supported SSL backends:
        schannel

i'm not sure where to start to investigate this, so pointers to what the authentication process or where its located in source at lest might give me a push in the right direction.

2. I successfully built a setup (thank for the instruction), but its not quite what i need for a few reasons: first the setup doesn't seem to contain the ARM64 git.exe that i built locally, not sure from where/what it grabbed its binaries. second, the setup didn't ask the usual Qs that setup asks, not sure if that is something i did wrong or not.

3. finally, related to setup: one path, which i think is a good one, in the direction toward getting something viable on ARM64 Windows is to get a setup that mixes 32-bit x86 and ARM64. (e.g. mingw32). This is because the emulator on ARM64 Windows only supports 32-bit x86 binaries.

Please let me know your thoughts on these topics.

thanks,
ian

[manbearian]

Spending time debugging fatal: Unsupported SSL backend 'openssl' has lead me to the conclusion that the libcurl i have is built without OPENSSL, (i see -DCMAKE_USE_OPENSSL=OFF in my build log) but that feature seems to be enabled in the version that i have installed. When i run git config --system -l i see http.sslbackend=openssl, and this setting seems to be sending git-remote-http.exe down the path that won't work.

The libcurl dependency is a vcpkg dependency... so i didn't run any configuration on it: is there possibly something strange here? Is this is a scenario that is not tested in VS build scenario?

Additional help is appreciated.

[rimrul]

Have you seen microsoft/vcpkg#9683?

To get openssl support with vcpkg curl you apparently need to run vcpkg install curl[core,openssl]

[manbearian]

@rimrul , thanks. that was my conclusion as well from reading the vckpg docs, but that still leaves open my second question: Is this is a scenario that is not tested in VS build scenario?

How far into uncharted territory am i right now?

[dscho]

How far into uncharted territory am i right now?

Far ;-)

Last time I tried to compile for ARM, vcpkg did not support building OpenSSL for ARM. But you might be able to build cURL with "winssl" (also known as "Secure Channel") support, which is provided by Windows, so there is no need to compile that yourself. This backend is essentially an alternative to using OpenSSL, and also allows cURL to connect via HTTPS.

[dscho]

Cloning into 'c:\msvc1'...
fatal: Unsupported SSL backend 'openssl'. Supported SSL backends:
schannel

Nevermind, I should have read back further: schannel is what you want to use. You can configure it via git config --global http.sslBackend schannel.

[rimrul]

That should be possible to determine using IsWow64Process2().

[dscho]

That should be possible to determine using IsWow64Process2().

Heh, I just added this suggestion 15 minutes ago: git-for-windows/MINGW-packages#44 (comment)

[rimrul]

According to this blog post from 2017 it should work, but we might need to be careful on Windows 10 prior to 1709.
We might be able to get by with just using it via compat/win32/lazyload.h which we should do either way to avoid breaking the x86 build for Windows versions below 10.

[dennisameling]

Good idea, thanks for sharing! Will check it now

[dennisameling]

It works with IsWow64Process2()!! 🎉 Just tested with my simple demo C++ project.

x86/i686 executable on ARM64 device:

x86/i686 executable on x64 device:

I'll spend some time this weekend to see how I can incorporate this in the git-wrapper.c together with lazy loading, to prevent issues with Windows versions lower than Windows 10 1709. To be continued 🚀

[dscho]

According to this blog post from 2017 it should work, but we might need to be careful on Windows 10 prior to 1709.
We might be able to get by with just using it via compat/win32/lazyload.h which we should do either way to avoid breaking the x86 build for Windows versions below 10.

Well, we're talking about the Git wrapper here, so it would need to do its own LoadLibraryExW() thing instead of using the niceties of lazyload.h.

[rimrul]

git-wrapper.c is part of mingw-w64-git and the PKGBUILD file lists git-for-windows/git as part of its sources, so shouldn't we be able to just do #include "compat/win32/lazyload.h" in git-wrapper.c?

[dennisameling]

Got it to work (including on Windows 8.1, haven't tested Win7) in git-for-windows/MINGW-packages#44 🎉

[dscho]

git-wrapper.c is part of mingw-w64-git and the PKGBUILD file lists git-for-windows/git as part of its sources, so shouldn't we be able to just do #include "compat/win32/lazyload.h" in git-wrapper.c?

So far, git-wrapper.c does not include anything from Git's source code, to avoid having to link libgit.a.

I suppose that lazyload.h does not require libgit.a to be linked in, but it sure muddies the water if we allow that header to be #included but no other of Git's header files.

[rimrul]

I would've liked the internal consistency of doing this kind of dynamic function loading the same way throughout the Git for Windows code base, but I see your point.

Seems like Dennis already picked the loading implementation from the blog post anyways.

[dennisameling]

Update: we're making great progress. I was able to create a PortableGit installer for ARM64, you can try it out here: https://github.com/dennisameling/git/releases/tag/2.30.0-beta2 🚀

To see an overview of open PRs for the ARM64 work please see this comment.

Here's how it works:

This is basically a mingw32 build, but with some logic to recognize if the user is running on an ARM64 device. If they are, it will look first in an additional directory called arm64, which has some native binaries in it like git.exe. This is what will give you the ~2x speed boost in commands like git clone. Other binaries like curl aren't available natively for ARM64 yet, so Git Bash will fallback to mingw32 for those binaries.

So it first looks in /arm64 (1) and if the binary is not available there, falls back to /mingw32 (2):

Here you can see that it indeed uses Git from /arm64/bin/git:

We're getting very close everyone! Exciting times 🎉

[0cyn]

@dennisameling seems like that release was removed, any word on it?

[dennisameling]

@KritantaDev sorry, I had to re-fork this repo. Just uploaded the beta release again on the same URL, could you please try again now? 😊

[ranieuwe]

I tried to load the most recent version of @dennisameling fork builds v2.31.0-rc2.windows.2 but it doesn't run on Surface Pro X/ARM64. I do not have VCRUNTIME140.DLL. This is part of the vc redistributable 2015, but that one doesn't come in an ARM64 version, so can't install it.

[Alovchin91]

Please refer to this page:
https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0

You need to install both x86 and arm64 versions.

@dennisameling I wonder if the installer should somehow provide info on how to get the C++ Redist 🤔

[dscho]

I wonder if the installer should somehow provide info on how to get the C++ Redist

Or even better, have a checkbox that downloads it from somewhere and installs it. If needed, of course.

[Alovchin91]

🤔 With the latest version of Inno Setup (6.1.2) it should be perfectly possible indeed

[rimrul]

I'm not sure if that would count as the redistributables accompanying our executables, in terms if the GPL, though.

[walbourn]

TL;DR: Install either the VS 2017 or VS 2019 ARM64 redist.

The VS 2015 Update 3, VS 2017, and VS 2019 all share the same Visual C/C++ Runtime. That means the VS 2019 ARM64 version of the redist includes VCRUNTIME140.DLL that is compatible with these older versions of Visual Studio.

VS 2017 (15.9) i.e. Update 9 added support for ARM64. Official public Win32 desktop for ARM64 development was added in VS 2019, but in practice the compiler is not that different and was working internally back in VS 2017.

VS 2015 supported ARM for UWP, but not ARM64 which is why you can't find a ARM64 version of the VS 2015 REDIST.

[driver1998]

I wonder if it is possible to use the MSYS2 clangarm64 packages instead of mingw32 packages, for even more native stuff? Also move git.exe to /clangarm64 instead of /arm64 to align with MSYS2.
Things like cURL are already available in clangarm64: https://packages.msys2.org/base/mingw-w64-curl

[Alovchin91]

I second this, especially given that @dennisameling has built the ARM64 version using the LLVM toolchain anyway.

[dscho]

Mentioning such a suggestion is most likely to be much, much quicker than actually implementing it.

Could you try to modify https://github.com/git-for-windows/git/blob/HEAD/.github/workflows/git-artifacts.yml to do a full build? You will most likely figure out really quickly just what amount of work this is.