-
Notifications
You must be signed in to change notification settings - Fork 67
Support cross-building for ARM64 #91
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
Conversation
@qmfrederik This does look interesting, but I have a few questions, which will likely lead to a few additional changes here.
If you look at the supported OS documents for .NET Core: Microsoft is only currently supporting ARM32 for Debian 9 and Ubuntu 16.04+. I'm not sure I'd want to add ARM64 binaries at this point since they don't actually support it. They are adding ARM64 support for .NET Core 3.0: https://github.com/dotnet/core/blob/master/release-notes/3.0/3.0-supported-os.md But we don't know a release date for that yet. If we're going to be start providing ARM binaries at all, I would think we'd want ARM32 as well here if possible. One of the other reasons I've not done this before is that I'm not currently aware of a way to actually test the binaries. Are you aware of any CI systems that provide ARM cpus to run on? |
There's also the question of which RIDs we actually have to build for to get the full coverage needed here, which will require some investigation. |
@bording Sure, here you go:
At the time .NET Core 2.2 shipped, the story was that there was support for ARM64 although you'd ideally cross compile from x86 to ARM64. The current story is that ARM64 is only being maintained in master (.NET Core 3.0). I can definitively extend this PR/create a new PR which cross compiles for ARM32, too, if that helps. Just keep in mind that you can't as easily run an ARM32 binary on an ARM64 version of Linux as you can mix 32-bit and 64-bit apps on Intel architectures. Regarding to CI, I currently rely on https://cloud.drone.io which provides free access (for open source projects) to some very beefy ARM64 hardware (and x64 as well, for that matter). Again, I can help out here as well if needed. Regarding the RIDs, I've more or less copied what you've done for x64, but limiting myself for the Debian/Ubuntu flavors. Personally I avoid shipping native libraries for the |
I find it strange that Microsoft is providing ARM64 binaries for 2.1 and 2.2 given that they say they only support ARM32 and that ARM64 support is only for 3.0. I also noticed that it looks like ASP.NET Core binaries are ARM32-only. Take a look at the download links here: https://dotnet.microsoft.com/download/dotnet-core/2.2 So, ARM32 seems to be the actual architecture we'd want to support, for shipping versions of .NET Core.... but given that ARM64 support is coming soon with .NET Core 3.0, both ARM32 and ARM64 makes sense to me. |
For the existing set of RIDs, those were chosen based on trying to have the minimum number of separate binaries possible to cover the supported platforms. The considerations are around these things
The existing choices for RIDs likely won't be right to just include ARM32/ARM64 versions, so we'll need to figure out the actual set we'll need. |
So, here are the dependencies for arm64 (I've added the Dockerfiles I've used for reference purposes):
You could try to go with the builds for Debian 9 as The only other distro which is/will be supported for arm64 is Alpine Linux. It looks like Alpine doesn't ship with a cross-compilation toolchain (at least I couldn't find the required packages), and the only option is to cross-compile for Alpine arm64 from another distro such as Ubuntu - e.g. https://github.com/dotnet/coreclr/issues/8927 describes how we did it for CoreCLR itself. I don't have a need for Alpine arm64 at the moment; would it be OK to leave that for later/someone else? |
Sure, we can always work on that later. Similar to my comment on the ARM32 PR: #92 (comment) I think we could try for I don't have access to any ARM hardware myself, so would you be able to help test this? I'm trying to think of what would be the easiest way to actually try using the binaries to verify they work. At some point, I'd like to get the LibGit2Sharp repo running tests on all the relevant repos (libgit2/libgit2sharp#1634), but that's not currently in place. |
@qmfrederik Can you update the PR so that we build the following binaries:
If you do that, I should be able to build a preview version of the binaries package that you could use to run the LibGit2Sharp tests. I'm hoping the debian binary will also work fine on Ubuntu 18.04 and 18.10. |
Yes, let me take care of that today. Sorry, lost track of this during the Easter holiday. |
@bording Yes, I think that would work - the Debian image would be used for Debian 9, Ubuntu 18.04 and Ubuntu 18.10. They all use the same version of OpenSSL so we should be good there; and then there's a special case for Ubuntu 16.04. I rebased on top of master and pushed an additinal commit which incorporates your feedback. You'll probably want to squash all commits if you merge this. If you want me to squash first, let me know. |
@qmfrederik I have uploaded LibGit2Sharp.NativeBinaries 2.0.280-armpreview01. You should be able to use that with the LibGit2Sharp repo to verify that the binaries do in fact work like we think they will. Once you've done that, I'll merge this (most likely squashing things when I do), and then we can do the same thing for the arm32 PR. Once both of them are in, I'll push up a real package update and then I'll create a LibGit2Sharp 0.27 prerelease that uses it. |
@bording Thanks, I ran a test and it appears the libraries are indeed working correctly. Here's the full test output:
So as far as I can see, things look good... |
To clarify, which version of Ubuntu was this?
Hmm, that seems strange. Something to figure out later I suppose.
Of course, since it uses LibGit2Sharp! Will have to think about how to handle this for the first release so NB.GV can update! |
Ubuntu 18.04, so it seems like building building for Debian 9 and packaging it as |
Long story short, I'm trying to use NerdBank.GitVersioning in a .NET Core project which runs on a Raspberry Pi, which means I'd need an ARM64/aarch64 version of libgit2, too.
This PR adds:
CMakeLists
file which configures CMake to cross-compile for arm64Dockerfile
s (Ubuntu 18.04 for now) which install the cross-compile toolchains and run the build.After this: