Tracking issue for Windows ARM64 support #3107
Comments
|
I'm a bit focused on making sure that the v2.31.0 release goes smoothly, and will be happy to pay more attention to the ARM64 side of things after that release is out (which will probably happen Tuesday or Wednesday this coming week). |
|
Hi @dennisameling , Thanks for your wonderful work! ❤️ Have been using MinGit lately (which is a 💎 by itself) and it works great on my SPX! One thing I just found: While MinGit doesn't seem to contain Could you please check on your side, on a complete Git setup? Thanks a lot! 😃 |
|
The documentation is not built as part of the CMake-based build. It will take quite some work to implement that. @Alovchin91 that's your chance to get involved! 😉 |
|
@dscho I would be happy to help, but right now my capacity is extremely limited unfortunately and I have never had any proper experience with Cmake. But wouldn't it be enough to point Git.exe from arm64 folder to the documentation in mingw32? 🤔 |
Not really, because the build configuration may differ in more than just the CPU architecture, even in ways affecting how/what parts of the documentation are compiled. |
|
Hmm, I think right now my concern is mostly about where does arm64 version look for docs in a full installer-based version of Git 🤔 I saw that it's also absent from the "normal" mingw32 MinGit build, so I suppose missing docs in those builds is not arm64 specific issue. |
|
Right, documentation is excluded from MinGit builds. But looking for the documentation in the wrong location, just because there is no documentation in the correct location, isn't a solution for the non-MinGit flavors of Git for Windows, either ;-) |
|
Ah, right, now I get your point 😁 For some reason I thought that the most part of the tools are redirected to mingw32 folder and arm64 only contains wrappers or helpers 😅 |
|
Thanks to @dennisameling tireless work, the Git executables are built for Windows/ARM64. The i686 version of the MINGW tools we're still relying on are things like |
|
Can confirm the help docs are only present in The help function looks at Lines 464 to 482 in 959b2f0 This is defined in the CMake file: git/contrib/buildsystems/CMakeLists.txt Lines 206 to 217 in 959b2f0 @dscho would you be okay with a clause in the CMake file for Win ARM64 that sets |
I wonder how much work it would be to optionally use |
Will have a look in the coming days. Just created a PR for 64-bit ARM64 installer support: git-for-windows/build-extra#333 |
|
@dscho now that the 64-bit ARM64 installer PR has been merged, do you think we're ready to release a beta build of Git for Windows ARM64? I'm happy to look into the docs thing with |
It'll probably run daily and check for updates, but when it detects an update, it'll try to download and install the x86 installer. |
Yes, I think we're getting to the point where we want to invite testers (I, unfortunately, am not eligible because I lack the hardware).
Fantastic. I do think that it should be possible to add that to the
Indeed. For I could imagine that we would probably want to improve on that e.g. by enhancing diff --git a/git-extra/git-update-git-for-windows b/git-extra/git-update-git-for-windows
index 7121dd7be..50ff5524a 100755
--- a/git-extra/git-update-git-for-windows
+++ b/git-extra/git-update-git-for-windows
@@ -174,7 +174,22 @@ update_git_for_windows () {
;;
esac
- latest_tag_url=https://gitforwindows.org/latest-tag.txt
+ if test -f "$0.ini"
+ then
+ fork="$(git config -f "$0.ini" update.fromFork)"
+ test -n "$releases_url" || {
+ echo "Could not find update.fromFork in $0.ini" >&2
+ return 1
+ }
+ releases_url=https://api.github.com/repos/$fork/releases
+ latest_tag_url=$releases_url/latest
+ latest_eval='latest=${latest_tag#*\"tag_name\": \"}; latest=${latest%%\"*}'
+ else
+ releases_url=https://api.github.com/repos/git-for-windows/git/releases
+ latest_tag_url=https://gitforwindows.org/latest-tag.txt
+ latest_eval='latest=${latest_tag#v}'
+ fi
+
latest_tag=$(http_get $latest_tag_url) ||
case $?,"$proxy" in
7,)
@@ -190,7 +205,7 @@ update_git_for_windows () {
;;
esac
- latest=${latest_tag#v}
+ eval "$latest_eval"
# Did we ask about this version already?
recently_seen="$(get_recently_seen)"
test -n "$quiet" && test "x$recently_seen" = "x$latest" && return
@@ -215,7 +230,6 @@ update_git_for_windows () {
esac
echo "Update $latest is available" >&2
- releases_url=https://api.github.com/repos/git-for-windows/git/releases
releases=$(http_get $releases_url/latest) || return
download=$(echo "$releases" |
grep '"browser_download_url": "' | |
Right, completely forgot to address that part. We do trust |
I was thinking a lot simpler: We could check |
|
I don't really trust |
|
I opened git-for-windows/build-extra#338 to help with this. |
|
Incredibly excited that git-for-windows/build-extra#340 has been merged. I almost don't dare to ask, but do you think we're now ready to release a beta version of Git for Windows ARM64, @dscho (apart from the request for the docs, which I hope to look into in the coming two weeks)? 🤞🏼
I ordered and received a Raspberry Pi 4 last week, then installed Windows on ARM 19043 (21H1) on it. The performance is surprisingly good, but every once in a while there's a little driver-related hiccup that the Windows on Raspberry team is working hard on. If you want, I can send you the TeamViewer ID + password so you can test a bit on your end as well 👍🏼 |
|
I have the Surface Pro X so I can also help with testing 🙂 RDP is also an option. |
|
Right now, I would like to focus on Git for Windows v2.32.0, for which -rc0 came out yesterday, and the final version is expected around June 7th/8th. After that, I'm all game for ARM64 and will take y'all up on the kind offers to let me connect to your hardware. |
|
Well... I wonder if BUILD next week brings anything interesting to arm64 world anyway 🤷 Maybe an arm64 GitHub Actions pipeline? One could dream... |
|
@dennisameling Could you add the issue with While it isn't a show stopper for the ARM beta it would be nice to have that fixed before we get more ARM bug reports. |
|
Okay, I hope it's finally time to prepare the first ARM64 beta! 🤗 Please let me know if I can help with anything. I could provide an ARM64 virtual machine on my Surface Pro X for a build pipeline, for example 🙂 |
|
Just updated the list above with open issues. I recently came across the fact that Visual C++ is needed since we use MSVC for the ARM64 builds. We can either include the Visual C++ Redistributable package in the installer, or statically build using MSVC (if possible). Do you have any preference here @dscho? I guess the latter option would be best as software like GitHub Desktop is depending on MinGit, so a static build would make their lives easier as well. |
|
I don't think UCRT can be statically linked and redistributing vcredist would probably be a GPL violation, so linking the vcredist download page is probably our only option. |
I am almost 100% certain that The approach I would want to try is to build a heavily-instrumented version of the MSYS2 runtime, littering debug print statements all over the place, in particular around creating and joining threads and starting child process and waiting for them. Then I would want to create a GitHub workflow that downloads a minimal Git for Windows SDK, just enough to code-sign something using Then I would experiment with the Should that not bear any fruit, I would pivot and try to reproduce the same hang in an interactive VM and then take it from there. |
|
Hi All, Was there ever any more progress with this, since discussion died off in August? I saw a few new builds on Dennis's fork, but is there ant progress to official builds? What is blocking the possibility to make releases? I did try and give building it myself a go, but I feel I must be missing some sort of steps somewhere, as I get all sorts of issues about missing MSYS2 hanging when exiting processes is sadly something we've run into across a few other projects also (blender, and some of our own internal CI builds), and haven't been able to track down. We typically end up going for the "time out and retry" approach. |
|
@dennisameling thank you for triggering https://github.com/git-for-windows/git-for-windows-automation/actions/runs/8025034802! I saw that some jobs stayed queued for quite a while because no runners were spun up. When I looked more closely, it seems that quite a few webhook deliveries encountered 404s and 504s, and it looks as if those problems are responsible. I kicked three workflow runs off manually, to create those runners. At least it looks as if all the runners were all torn down automatically and without problems. |
|
Hi everyone, here's the arm64 build of 2.44.0, built by the pipeline that @dscho mentioned above: https://github.com/dennisameling/git/releases/tag/v2.44.0.windows.1 🎉
That's interesting. I wonder if it was somehow related to the fact that there were dozens of jobs already running on the git-for-windows/git at that time. There's a limit to the number of parallel jobs that can run simultaneously in a GitHub account. But then it's surprising that the webhook returned 404s and 504s - I'd expect something like 429 instead. Today, I triggered the same workflow 3 more times to test the stability. All runners were created correctly, with the exception of some occasional rate limits on Azure. A simple retry after other runners had completed their work, was enough. Out of the total 4 times that I started the workflow, 1 ran into the issue with the
I agree that a simple "time out and retry" approach might be a viable path forward for now, since all hangs have been in the |
|
That strategy sounds good to me. FWIW I see a consistent hang on Windows/ARM64 also in |
|
The hang is documented here: git-for-windows/git-for-windows-automation#61 |
|
Pacman keeps hanging for me on emulated x64 as well. The latest version that works without hangs is 6.0.2-11. I’d suggest to downgrade it and ignore its updates for now until you have time and will to investigate. |
Good piece of information! Do you know what changed in the next version?
It is a symptom that may very well affect other scenarios, too. Including scenarios more relevant to Git users than Pacman. Downgrading would therefore not really help but paper over a potentially much bigger problem. That's why I don't want to do that. |
Based on https://github.com/msys2/MSYS2-packages/commits/master/pacman looks like msys2/MSYS2-packages@8c1bba7 ? Something to do with allowing weak key sigs in later gnupg releases from msys2/msys2-pacman#33 |
Thank you @chadlwilson! The change does not strike me as making anything worse, though, so I figure it may be a related change (maybe a |
|
Yeah, might be interesting to pin gnupg at |
|
I believe I’ve tried downgrading gnupg and it didn’t help. Downgrading pacman alone did help though. |
|
I have used arm64 pacman packages from @dennisameling's run from yesterday, and when installing them I've noticed some discrepancy between x64 and arm64 packages, more specifically:
The most interesting part probably being Now, obviously pacman wouldn't use the mingw package, but is there a good reason why these packages are not being upgraded? |
Yes. The consistent hangs during the |
|
Okay, but are there any updates? Has anybody tried downgrading pacman? This issue has been silent for months, I'm not even sure where to follow the progress anymore. |
I just tried downgrading |
|
I am hopeful that msys2/MSYS2-packages#4583 will allow us to avoid those hangs for the time being. |
|
Relevant news: GCC v15.1 is slated to support targeting |
|
Well, with the work-around from msys2/MSYS2-packages#4583 applied optimistically in git-for-windows/git-sdk-arm64#17, we now finally have a working, native Windows/ARM64
We also are finally in a state where MINGW-packages can be built for Windows/ARM64 without human intervention. I guess now comes the long game of playing catch-up: Script to generate# Extract the package metadata for a specific key (provided as first parameter)
# If no second parameter was provided, extract it from all packages, prefixing the value with `<package>:`
# If a second parameter was provided, use it as a prefix regex to match
# (this can have a `-[0-9]` suffix to match precise package names)
extract_desc () {
case "$2" in
*x86_64*)
remote=github;;
*)
remote=git-sdk-arm64;;
esac
# Skip `pacman` because it's so slow; Look at `/var/lib/pacman/local/*/desc` directly
# The `desc` files are contained in directories whose names have the format `<package-name>-<version>`
# The `desc` file has `%<key>%` lines which are followed by lines containing the values
git grep -A1 '^%'"$1"'%$' $remote/main:var/lib/pacman/local/ |
sed -n '/:%'"$1"'%$/{N;s|.*local/:\([^/]*\)/desc-|\1:|p}' |
if test -z "$2"
then
cat
else
sed -n "s|^$2[^:]*:||p"
fi
}
# Get all `mingw-w64-*` packages in `git-sdk-arm64` that have not been built by MSYS2 (but most likely by Git for Windows)
extract_desc PACKAGER |
grep '^mingw-w64-' |
grep -v ':CI .*autobuild' |
while read line
do
dir=${line%%:*}
x64_dir=mingw-w64-x86_64-${dir#mingw-w64-clang-aarch64-}
# Does `git-sdk-64` have the same version? If so, move along, nothing to be seen here
git rev-parse --verify github/main:var/lib/pacman/local/$x64_dir >/dev/null 2>&1 && continue
ver_arm64=$(extract_desc VERSION "$dir")
package_name=$(extract_desc NAME "$dir")
ver_x64=$(extract_desc VERSION mingw-w64-x86_64-${package_name#mingw-w64-clang-aarch64-}-[0-9])
echo "mingw-w64-${package_name#mingw-w64-clang-aarch64-} | ${ver_x64:-N/A} | $ver_arm64"
done
Note: I think this might be missing some packages (IIRC |
|
@dscho This is fantastic news! 🎉 Does that mean arm64 packages can now be published to the Git for Windows aarch64 Pacman repo? |
I've started the deployment workflow And I messed up something in copy&paste |
git-for-windows/MINGW-packages#114 (comment) I think it was built and deployed. |
|
For the various clang/llvm packages I won't get around to updating git-for-windows/MINGW-packages#115 today, but I'll try to get it done tomorrow. |
@Alovchin91 they already are, git-sdk-arm64 uses that Pacman repository.
Thank you @rimrul!
Hah, it would look as there were substantial gaps in my feeble attempt to see what packages versions still need to be built for versions_arm64="$(git show git-sdk-arm64/main:var/lib/pacman/sync/git-for-windows-aarch64.db |
tar OxJvf - 2>/dev/null |
sed -n '/^%NAME%$/{n;x};/^%VERSION%$/{n;G;s/\(.*\)\n\(.*\)/\2:\1/;p}')"
versions_x64="$(git show github/main:var/lib/pacman/sync/git-for-windows.db |
tar OxJvf - 2>/dev/null |
sed -n '/^%NAME%$/{n;x};/^%VERSION%$/{n;G;s/\(.*\)\n\(.*\)/\2:\1/;p}')"
for pair in $(echo "$versions_arm64" | grep '^mingw-w64-')
do
pkg_arm64=${pair%%:*}
ver_arm64=${pair#*:}
pkg_x64=mingw-w64-x86_64-${pkg_arm64#mingw-w64-clang-aarch64-}
ver_x64="$(echo "$versions_x64" | sed -n "s|^$pkg_x64:||p")"
test "$ver_x64" = "$ver_arm64" ||
echo "mingw-w64-${pkg_x64#mingw-w64-x86_64-}|${ver_x64:-N/A}|$ver_arm64"
done
The outcome is the same, thankfully: we only need to rebuild |
It doesn't look like Git and Git-Docs packages are included though: That's why I've been asking Dennis about the packages.tar.gz artefact in another thread -- the only way to install Git-arm64 as a package right now is to download the artefact and |
@Alovchin91 that's correct. For the time being, there is not (yet) any official Git for Windows/ARM64.
FWIW this second attempt might look like it's stuck when trying to follow live, but I just RDPed into the runner to see whether it is running things and it does. I also see that OpenSSL's tests are not run in parallel; Not sure why, but it certainly does not utilize the VM very well. |
@rimrul it worked! |
|
Just a quick note from me: While I no longer work at Microsoft, @marcpems and @jamshedd continue to drive things and am sure will be just as excited that I am that Git for Windows on Arm is edging ever closer to being completed and officially released. GREAT work @dscho, @Alovchin91, @rimrul, @chadlwilson, and @dennisameling (& anyone else I've missed) - you're all rockstars, thank you!!! |
and others
There's been a discussion about Windows ARM64 support here: #3021
I made a discussion comment there to keep track of the outstanding tasks to get basic ARM64 support to Git for Windows. However, @Alovchin91 informed me via Twitter that it was hard to keep track of the progress that way, requesting a dedicated issue. So here it is 😊
Open tasks for basic ARM64 support:
/etc/profileadded MSYSTEM=ARM64 case in /etc/profile git-sdk-32#6/etc/profileingit-extra.install.inStart support for MSYSTEM=ARM64 build-extra#321git-wrapperinmingw32to use the nativegit.exe, setMSYSTEM=ARM64, etc. Add arm64 support to git-wrapper MINGW-packages#44git pushetc.) by referencing it from themingw32directory Git Credential Manager Core missing in ARM64 libexec folder #3015git-artifactsworkflow #3053cmd\git.exeis crashing whenarm64/binfolder is present cmd\git.exe crashing when ARM64 folder is present in Git installation (git-wrapper) #3083git --version --build-optionsreturnsAMD64as the CPU cmake(): allow setting HOST_CPU for cross-compilation #3327--help(example:git log --help) doesn't work since Git looks for docs in the wrong locationThanks to the changes that we did in the last few days, there's now a fully working build of Git for Windows ARM64.
Test build for ARM64 users, built on March 12, 2021: https://github.com/dennisameling/git/releases/tag/v2.31.0-rc2.windows.2
I think we're pretty much ready to publish a beta version of Git for Windows ARM64! @dscho what do you think? Please let me know if I missed something in the list above.
The text was updated successfully, but these errors were encountered: