search

git-for-windows / git

A fork of Git containing Windows-specific patches.
http://gitforwindows.org/
Other
8.19k stars 2.49k forks source link

Tracking issue for Windows ARM64 support #3107

Open dennisameling opened 3 years ago

dennisameling commented 3 years ago

There's been a discussion about Windows ARM64 support here: https://github.com/git-for-windows/git/discussions/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:

Thanks 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.

dscho commented 3 years ago

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).

Alovchin91 commented 3 years ago

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:

C:\Projects\rustup>git log --help
fatal: 'C:/MinGit/arm64/share/doc/git-doc': not a documentation directory.

While MinGit doesn't seem to contain git-doc anyway, what caught my attention is that git.exe tries to search for documentation in the arm64 directory, while docs seem to still be in mingw32.

Could you please check on your side, on a complete Git setup? Thanks a lot! 😃

dscho commented 3 years ago

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! :wink:

Alovchin91 commented 3 years ago

@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? 🤔

dscho commented 3 years ago

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.

Alovchin91 commented 3 years ago

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.

dscho commented 3 years ago

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 ;-)

Alovchin91 commented 3 years ago

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 😅

dscho commented 3 years ago

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 curl.exe, but we do include all of the i686 Git executables at the moment, too.

dennisameling commented 3 years ago

Can confirm the help docs are only present in mingw32\share\doc\git-doc on a full installation and not in arm64\share\doc\git-doc.

The help function looks at GIT_HTML_PATH to find the help docs:

https://github.com/git-for-windows/git/blob/959b2f0c6fb12f8ba13f9015c4482fa8133b7f9c/builtin/help.c#L464-L482

This is defined in the CMake file:

https://github.com/git-for-windows/git/blob/959b2f0c6fb12f8ba13f9015c4482fa8133b7f9c/contrib/buildsystems/CMakeLists.txt#L206-L217

@dscho would you be okay with a clause in the CMake file for Win ARM64 that sets GIT_HTML_PATH to ../mingw32/share/doc/git-doc for the time being? We can leverage the already available CMAKE_GENERATOR_PLATFORM for that logic.

dscho commented 3 years ago

would you be okay with a clause in the CMake file for Win ARM64 that sets GIT_HTML_PATH to ../mingw32/share/doc/git-doc for the time being?

I wonder how much work it would be to optionally use asciidoctor or asciidoc, if configured. These lines describe how asciidoc is called: https://github.com/git/git/blob/v2.31.0/Documentation/Makefile#L125-L133 And these describe how asciidoctor would be called instead: https://github.com/git/git/blob/v2.31.0/Documentation/Makefile#L179-L190

dennisameling commented 3 years ago

I wonder how much work it would be to optionally use asciidoctor or asciidoc, if configured.

Will have a look in the coming days.

Just created a PR for 64-bit ARM64 installer support: https://github.com/git-for-windows/build-extra/pull/333

dennisameling commented 3 years ago

@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 asciidoctor and asciidoc mentioned above, but will only have time for that after May 7 due to work responsibilities and a break 😊 Thanks in advance!

rimrul commented 3 years ago

Check if the daily "Git for Windows update check" works correctly on ARM64

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.

dscho commented 3 years ago

do you think we're ready to release a beta build of Git for Windows ARM64?

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).

I'm happy to look into the docs thing with asciidoctor and asciidoc mentioned above

Fantastic.

I do think that it should be possible to add that to the CMakeLists.txt definition (a quick search brought up https://github.com/gdamore/nanomsg/commit/55921246a02a8d9581fbb6e961a6aae3aadbb2c7 which might be a good example to follow, although I would try not to have a separate Boolean to enable documentation; Rather, I would make it conditional on a check that tries to find asciidoc or asciidoctor, allowing the user to specify a hard-coded path to either to side-step the discovery).

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.

Indeed.

For microsoft/git, I already did something slightly ugly to redirect the git update-git-for-windows command: https://github.com/microsoft/git/pull/321#issue-605488512. Essentially, it is a hack that edits the git-update-git-for-windows script to target a different update site, via a few sed commands.

I could imagine that we would probably want to improve on that e.g. by enhancing git-update-git-for-windows itself. One option would be to search for a file, say, git-update-git-for-windows.ini next to the script (when called via the PATH, as git update-git-for-windows will do internally, "$0" contains the absolute path to the script, therefore "$0.ini"would refer to that.inifile's path). If found, it would override a couple of things. Something along these lines (applies tobuild-extra`, but reader beware: this is totally untested):

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": "' |
dscho commented 3 years ago

❓ Check if the daily "Git for Windows update check" works correctly on ARM64

Right, completely forgot to address that part. We do trust uname -m in the git-update-git-for-windows script, but on ARM, we cannot (because our MSYS2 will be an i686 or an x86_64 one).

rimrul commented 3 years ago

I could imagine that we would probably want to improve on that e.g. by enhancing git-update-git-for-windows itself. One option would be to search for a file, say, git-update-git-for-windows.ini next to the script (when called via the PATH, as git update-git-for-windows will do internally, "$0" contains the absolute path to the script, therefore "$0.ini"would refer to that.ini` file's path). If found, it would override a couple of things.

I was thinking a lot simpler: We could check $MSYSTEM or $MINGW_MOUNT_POINT to detect we're on an ARM install. Admittedly, I did not think about microsoft/git when I had that idea.

dscho commented 3 years ago

I don't really trust MSYSTEM and MINGW_MOUNT_POINT at this stage ;-) If git.exe sets MSYSTEM, for example, it will not have the expected value.

dscho commented 3 years ago

I opened https://github.com/git-for-windows/build-extra/pull/338 to help with this.

dennisameling commented 3 years ago

Incredibly excited that https://github.com/git-for-windows/build-extra/pull/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)? 🤞🏼

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).

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 👍🏼

Alovchin91 commented 3 years ago

I have the Surface Pro X so I can also help with testing 🙂 RDP is also an option.

dscho commented 3 years ago

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.

Alovchin91 commented 3 years ago

Well... I wonder if BUILD next week brings anything interesting to arm64 world anyway 🤷 Maybe an arm64 GitHub Actions pipeline? One could dream...

rimrul commented 3 years ago

@dennisameling Could you add the issue with git --version --build-options that I pointed out in #3083 to the list?

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.

Alovchin91 commented 3 years ago

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 🙂

dennisameling commented 2 years ago

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.

rimrul commented 2 years ago

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.

Alovchin91 commented 2 years ago

UCRT redistributable files should be okay to include with Git for Windows: https://docs.microsoft.com/en-us/visualstudio/releases/2019/redistribution#visual-c-runtime-files

It's also perfectly possible to link UCRT statically: https://docs.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=msvc-160 :)

rimrul commented 2 years ago

UCRT redistributable files should be okay to include with Git for Windows: https://docs.microsoft.com/en-us/visualstudio/releases/2019/redistribution#visual-c-runtime-files

I'm not a lawyer in the US, but unless I'm missreading the GPL, redistributing the UCRT redistributable files as part of Git for Windows without also redistributig the source code for them is illegal.

It's also perfectly possible to link UCRT statically: https://docs.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=msvc-160 :)

Ok, that should be legal.

tommyvct commented 2 years ago

Here's some references from OBS Studio, they included the VC++ redistributable with the installer then silently install them. So either static linking or bring the redistributable is fine legal wise.

Alovchin91 commented 2 years ago

Shouldn't it be perfectly legal to download the dependency from an official website and install it as part of setup? See https://github.com/DomGries/InnoDependencyInstaller

rimrul commented 2 years ago

Shouldn't it be perfectly legal to download the dependency from an official website and install it as part of setup?

For non-GPL applications? Yes. For GPL applications? Maybe.

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

Does automatically downloading the redistributables during setup legally count as the redistributables accompanying our executables? If so we clearly need to provide source code for them.

Here's some references from OBS Studio, they included the VC++ redistributable with the installer then silently install them.

That's quite clearly in violation of the GPL, they just decided to ignore it.

See also https://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL

I'm writing a Windows application with Microsoft Visual C++ (or Visual Basic) and I will be releasing it under the GPL. Is dynamically linking my program with the Visual C++ (or Visual Basic) runtime library permitted under the GPL? (#WindowsRuntimeAndGPL)

You may link your program to these libraries, and distribute the compiled program to others. When you do this, the runtime libraries are “System Libraries” as GPLv3 defines them. That means that you don't need to worry about including their source code with the program's Corresponding Source. GPLv2 provides a similar exception in section 3.

You may not distribute these libraries in compiled DLL form with the program. To prevent unscrupulous distributors from trying to use the System Library exception as a loophole, the GPL says that libraries can only qualify as System Libraries as long as they're not distributed with the program itself. If you distribute the DLLs with the program, they won't be eligible for this exception anymore; then the only way to comply with the GPL would be to provide their source code, which you are unable to do.

Alovchin91 commented 2 years ago

Right, so redistributing them with the program (which I guess means including them in any of Git for Windows' folders) is not permitted, check. But linking against them is perfectly fine.

But the installer is not a derivative work, right? The installer is a completely separate program, it's not even part of an original Git. Thus, if the installer itself (e.g. installer.iss I guess) is licensed separately, it could download and install the redistributables. I suppose the installer could be an explicit exception from the Git for Windows license.

Maybe the easiest way to begin with would be to link them statically for now 🤷‍♂️

Alovchin91 commented 2 years ago

I actually wonder if it's possible to link VC++ libraries statically while still linking UCRT dynamically 🤔 https://docs.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-the-universal-crt?view=msvc-160

Maybe MSYS2 UCRT subsystems or llvm-mingw have the answer to this question 🤔

There's also mingw-w64-clang-aarch64-toolchain available now and I wonder what does it link against. I'm gonna try it out 🙂

Alovchin91 commented 2 years ago

BTW I definitely don't want to neglect the wonderful job done by @dennisameling on enabling Git for Windows ARM64 with x86 emulation 🚀 but what do you think about ARM64EC as a way forward? Again, this is just a question, not a suggestion to change the direction.

rimrul commented 2 years ago

what do you think about ARM64EC as a way forward?

That would probably come in handy, but it would raise the requirements for Git for Windows on ARM64 to Windows 11. Looking at the supported Operating Systems on x86 and AMD64, I'm not sure we'd want to take that step. Then again ARM64 devices that support Windows 10 but not Windows 11 might be quite rare, so this might be a non-issue.

We'd also have to patch pacman to support packages loading dependencies from a different arch if they don't exist for the prefered arch.

Alovchin91 commented 2 years ago

Hmm, it turns out mingw-w64-clang-aarch64-toolchain is not a cross compiler, but an actual ARM64 LLVM toolchain 🤔 And while it links against UCRT, it doesn't seem to link against VC++ Redistributable DLLs.

How hard would it be to compile Git for Windows using LLVM toolchain? 🤔

tommyvct commented 2 years ago

ARM64EC isn't a new thing. Windows 10 can run ARM64EC binaries too.

Alovchin91 commented 2 years ago

ARM64EC is part of Cobalt branch which never made it into Windows 10 after all. So it's Windows 11 exclusive, but I don't see a problem here. Windows 11 can run on most ARM PCs, except the ones with Snapdragon 835. But then again, Git for Windows on ARM has never been released yet. So I believe it's still an option to go Windows 11 directly.

dennisameling commented 2 years ago

BTW I definitely don't want to neglect the wonderful job done by @dennisameling on enabling Git for Windows ARM64 with x86 emulation

Don't worry about that, I'm more than happy to change directions if that's best for the project.

Regarding the comments above, here's my thoughts:

Visual C++ Redistributable/static linking

I'm still more learning towards going the static linking route. The "regular" Git for Windows i686/amd64 is built using GCC/MinGW. That version doesn't need Visual C++, so my gut says that we should also be able to achieve that using the MSVC ARM64 build.

Again, since software like GitHub Desktop is using MinGit, they would also have to update their installer to include Visual C++ installation, which is quite a pain.

It's definitely possible to instruct CMake to let MSVC build statically linked binaries: https://cmake.org/cmake/help/latest/prop_tgt/MSVC_RUNTIME_LIBRARY.html

Also, the vcpkg libraries can be installed statically as well by doing .\vcpkg.exe install {PACKAGE}:arm64-windows-static instead of .\vcpkg.exe install {PACKAGE}:arm64-windows (which is dynamic by default).

I just tried that and was able to build a statically linked git.exe for ARM64 using MSVC (MultiThreaded /MT)🎉 

> .\git version
git version 2.31.1 GIT

The only thing that failed to build though was git-remote-http, so that would need further investigation.

ARM64EC

While this does sound attractive, I'm quite hesitant to using it since:

I think for the first version, it's good enough to stick to the native git.exe build and still open the i686/x86 binaries that aren't native yet like curl, bash, etc.

Build 21277 is the first build that allows running x64/amd64 binaries on ARM64. What we could do for the time being, is to ship Git for Windows ARM with both the mingw64 (amd64/x64) and mingw32 (i686/x86) folders. Then in the git-wrapper we can check if the user is on build 21277 or higher (using the IsWindowsVersionOrGreater API) and then load binaries from mingw64, otherwise fall back to mingw32 for the Windows 10 stable build. So you would still have the performance benefit of x64 binaries on builds 21277 and higher (which includes Windows 11) without needing ARM64EC. How does that sound @Alovchin91?

Alovchin91 commented 2 years ago

@dennisameling I think what you're saying makes perfect sense 🙂 I would suggest then to just push the current arm64 Git implementation out of the door already 😅 We can always think about x64 compatibility later, we have enough time before Windows 11 releases to the public anyway 🙂

The only thing though that I would like to try out is compiling arm64 Git binaries with LLVM (Clang). Visual Studio now also supports doing so, and at least MSYS2's clangarm64 subsystem is linked against libc++ AND ucrt, so there's no need for static linking or VC++ Redist.

Maybe @mstorsjo could share his thoughts on this? 🤔

rimrul commented 2 years ago

So you would still have the performance benefit of x64 binaries on builds 21277 and higher

How big of a performance benefit is that anyways? Maybe sticking to the combination of ARM64 and x86 and focussing on getting more x86 applications converted to ARM64 might be the better option.

I'd definitely put x64 on ARM64 down as something we consider after the first official release for ARM64.

dennisameling commented 2 years ago

How big of a performance benefit is that anyways?

I read somewhere that it can be up to 85% of native performance (compared to <50% in x86 emulation), but I guess that'll differ a lot depending on the application.

I agree that converting them into ARM64 would be even better and will be happy to look into that. Rich Turner from Microsoft indicated that they're planning to reach out to the MinGW team for a native ARM64 compiler soon. Clang would be an option as @Alovchin91 mentioned above, but I'm assuming that it will be more painful, given the large amount of packages that need to be built and potential bugs that will pop up. I guess that's a prerequisite for converting the MINGW-packages over to ARM64, right?

Regarding those potential bugs:

https://github.com/msys2/MSYS2-packages/issues/1888#issuecomment-596327631

As discussed in this thread Will There be an ARM/ARM64 Windows Support Soon?, the llvm-mingw can be used in MSYS2 environment to create ARM & ARM64 PE binaries. But it can not be fully replaced with GCC. Most of the packages (e.g. gmp, binutils, coreutils etc.) need some tuning for ARM. But it is possible to invoke llvm-mingw and compile higher level programs.

mstorsjo commented 2 years ago

Right, so redistributing them with the program (which I guess means including them in any of Git for Windows' folders) is not permitted, check. But linking against them is perfectly fine.

If the GPL compliance doesn't allow you to bundle Visual C++ runtime libraries with your app, I would expect it to disallow statically linking the same libraries too. But I'm not a lawyer.

Regarding ARM64EC, I woulnd't bother with that regarding Git, as the situation is more than complicated enough as it is, and bringing ARM64EC into the mix just makes it even harder regarding tooling availability etc.

How big of a performance benefit is that anyways?

I read somewhere that it can be up to 85% of native performance (compared to <50% in x86 emulation), but I guess that'll differ a lot depending on the application.

If those parts are performance sensitive then it might be worthwhile, but afaik the bulk of the heavy lifting should be part of git.exe itself which should be purely ARM64 native anyway?

I agree that converting them into ARM64 would be even better and will be happy to look into that. Rich Turner from Microsoft indicated that they're planning to reach out to the MinGW team for a native ARM64 compiler soon.

There's been an ongoing demand for GCC to support targeting ARM (and later AArch64) on Windows for many years (I looked at one such effort as early as 2014, with GCC maintainers being involved and writing initial proofs of concept, but none of those patches ever went upstream). I doubt that changes and that support materlizes overnight just because somebody from Microsoft suddenly reaches out and asks for it.

But a mingw toolchain targeting ARM64 already exists in the form of llvm-mingw and the ARM64 targets in MSYS2.

A mingw toolchain consists of building and bundling a couple projects together, e.g. GCC + binutils + the mingw-w64 SDK. You can replace GCC and binutils with LLVM and still have a "real mingw" toolchain.

LLVM can impersonate both the MSVC and GCC ABIs/behaviours; if you use LLVM/Clang in a MSVC setting, it'll use the Visual C++ runtime and you'll have all the same redistribution issues as you have right now. Or you can use LLVM/Clang in a mingw setting (where it impersonates the GCC style behaviours) and it will mostly work with all projects that expect a GCC/Mingw style toolchain. This is what llvm-mingw (my toolchain) ships as a standalone toolchain (both for cross compilation from unix, and as cross compilation from any of the 4 windows architectures to any of those 4 architectures), and what the clangarm64 subsystem in msys2 also tries to do.

Clang would be an option as @Alovchin91 mentioned above, but I'm assuming that it will be more painful, given the large amount of packages that need to be built and potential bugs that will pop up. I guess that's a prerequisite for converting the MINGW-packages over to ARM64, right?

FWIW, there's lots of ongoing work in upstream MSYS2, https://github.com/msys2/mingw-packages, for making sure as many packages as possible of theirs are buildable with Clang in the mingw configuration, by avoiding relying on odd corner case features in GCC/binutils that aren't implemented similarly in LLVM.

Secondly, to build bash and all other tools that run on the msys posix emulation layer, you'd need to have a compiler targeting cygwin, and I don't think the cygwin target in LLVM is up to date/working, I don't know of anybody who actually have tested it in a number of years at least. Bringing that up is another entirely different topic, and also probably requires porting the cygwin/msys2 runtime to arm as I'm sure it relies on lots of low level x86 specific details in its implementation.

mstorsjo commented 2 years ago

But put another way; the bits that you already successfully manage to build using MSVC for ARM64 should be pretty much straightforward to configure to build using llvm-mingw instead of MSVC (assuming there's a build system you can point at those compilers, with the GCC style interface), keeping everything the same but avoiding the Visual C++ Runtime redistribution issues: The code that is portable enough to work with both GCC and MSVC should have no problem being built with Clang (at most needing to fix a few ifdefs that assume only specific arch/compiler combinations).

rimrul commented 2 years ago

If the GPL compliance doesn't allow you to bundle Visual C++ runtime libraries with your app, I would expect it to disallow statically linking the same libraries too.

You're right, it doesn't. I think I had that confused with the GPLv3 GCC Runtime Library Exception.

dennisameling commented 2 years ago

But put another way; the bits that you already successfully manage to build using MSVC for ARM64 should be pretty much straightforward to configure to build using llvm-mingw instead of MSVC (assuming there's a build system you can point at those compilers, with the GCC style interface)

This sounds great, thanks for sharing. Yes, CMake is in place as a build system, so I did some tweaks in https://github.com/dennisameling/git/pull/1 and was able to build 67% of the whole project so far 👍🏼 will take some more time later this week to see if I can get working binaries out of it.

I think in general it'd be great to get things working on Clang, because as @mstorsjo has mentioned above, the MSYS2 team is already hard at work making their packages buildable with Clang as well 🚀

If we can at least get Git for Windows (without the packages, like we're doing now with MSVC) to build using Clang and work around MSVC that way, that'd be a great starting point.

tommyvct commented 2 years ago
  • git --version --build-options returns AMD64 as the CPU

I tried the same thing on arm64 WSL2, and it's displaying aarch64.

After a dig I found that the build system (CMake or Makefile) didn't take much consideration into cross compiling. They are using the host architecture (which the cross compiler will run on, in this case AMD64) for that value.

Evidence for CMake: https://github.com/git/git/blob/de88ac70f3a801262eb3aa087e5d9a712be0a54a/contrib/buildsystems/CMakeLists.txt#L197
Evidence for Makefile: https://github.com/git-for-windows/git/blob/3d45ac813c4adf97fe3733c1f763ab6617d5add5/Makefile#L1337-L1340

The Linux ARM64 version of git is probably compiled on a ARM64 machine, so it's correct there.

rimrul commented 2 years ago

Evidence for CMake: https://github.com/git/git/blob/de88ac70f3a801262eb3aa087e5d9a712be0a54a/contrib/buildsystems

CMAKE_SYSTEM_PROCESSOR should theoretically be the target architecture, but we either don't set that correctly or it gets overwritten somewhere.

rimrul commented 2 years ago

The Makefile also clearly says HOST_CPU should be set to the target architecture when crosscompiling and only falls back to a uname based value when unset.