-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ARM64 detection #43
ARM64 detection #43
Conversation
Signed-off-by: Tommy Vercetti <7903172+tommyvct@users.noreply.github.com>
Signed-off-by: Tommy Vercetti <7903172+tommyvct@users.noreply.github.com>
3 to 4 Signed-off-by: Tommy Vercetti <7903172+tommyvct@users.noreply.github.com>
@tommyvct I tried building with this PR, but am running into some issues.
BuildingHere are the steps I took for building with PKGBUILD:
This results in the following .zst files (I also took the folders from the |
Signed-off-by: Tommy Vercetti <7903172+tommyvct@users.noreply.github.com>
Thanks! I've updated the checksum. Let me know if you need help, thanks! |
Signed-off-by: Tommy Vercetti <7903172+tommyvct@users.noreply.github.com>
Okay so I was able to at least allow for a cross-compilation scenario (PR: msys2/MSYS2-packages#2283), but of course
I guess for now our best bet is to come up with a separate variable, so that the build command becomes something like |
I reckoned that we will need to fork the whole MSYS thing out for arm64, or at least the dependencies mentioned above. Introducing another variable does not help, to me this only introduce more confusion. As a temporary workaround, we can just left the forked MSYS thing completely unchanged, let it compile x86 binaries and call it arm64. It doesn't really matter in the short run since Windows on arm can run x86 binaries just fine, but we do need to move everything to arm64 eventually. For example, we can have With my wildest prejudice, these packages are portable enough that they can be compiled for Windows on arm with a simple swap of compiler backend. |
Agree with using the x86 binaries; that should significantly speed up our progress for now. Apparently cross-compilation to arm64 with GCC doesn't work (msys2/MSYS2-packages#2283 (comment)), but the msys2 team has work underway to add clang support if I understand correctly. For now, looking at your PR, it won't just work if we compile for mingw32 with I just created a separate PR that will allow us to run |
Why don't we do |
For some reason, the
|
Had that error as well yesterday. It's a missing dependency. Try |
So I tried with your PR (
As a quick fix I removed line 41 from
But the generated binary is still Any ideas? I really think #44 can be our fastest option for now, but let's explore this PR as well to see what's possible. @dscho will be back in the office on Monday, curious to hear his thoughts on this as well 👍🏼 |
I'm confused as well, I never got mine to work. |
Hmm. I don't know that we can realistically build a native ARM64 For now, I would suggest to pursue the approach instead where we completely side-step the MINGW package targeting ARM64. That is, build the ARM64 executables using the CMake approach, bundled as a This should be relatively easy given that the PortableGit-*.7z.exe really are self-extracting 7-Zip archives. It will be a bit harder to modify the (InnoSetup-based) installer, as the entire tooling assumes that you are running in a Git for Windows SDK compiled for the architecture you're targeting. So for now, I'd try to focus getting the |
I'll see what I can do on the installer side. Shouldn't be too hard to add ARM64 detection there. |
The challenge will be to work off of a Git for Windows SDK that has the ARM64 binaries in the correct place, and to teach |
This PR can be closed now that #44 has been merged 🚀 |
Indeed. Thank you, @tommyvct and @dennisameling! |
No description provided.