-
Notifications
You must be signed in to change notification settings - Fork 190
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
Add binary release for Linux on Apple Silicon M1 #236
Comments
wen |
Instructions for building from source are in the README: https://github.com/WebAssembly/wasi-sdk I don't know of anyone working on a linux arm64 build. We build our images using github CI I guess it depends on when we can actions runing on arm64 linux.. or somebody could figure out to do a cross-compile on x86? |
followup, needed
…On Thu, 18 Aug 2022 at 11.50 Sam Clegg ***@***.***> wrote:
Instructions for building from source are in the README:
https://github.com/WebAssembly/wasi-sdk
I don't know of anyone working on a linux arm64 build. We build our images
using github CI I guess it depends on when we can actions runing on arm64
linux.. or somebody could figure out to do a cross-compile on x86?
—
Reply to this email directly, view it on GitHub
<#236 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC6MWVJR55QMOM6GCOWEYTDVZWXHPANCNFSM5WGVR3RQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
+1 |
More info: In both containers, the error message is:
Any insight about how to workaround this? UPDATE: Issue described in #294 |
This issue is open for anyone to work on: from what I can tell, it would involve modifying the CI workflow, the CI scripts, and (perhaps) the Makefile. |
I started looking into this, locally the build went fine, and editing the ci workflows/scripts is straight forward. I think the bigger potential hold back here is where it would run. From what I can tell, Github currently only provides m1 runners in their "larger" runners offerings, which can get pricey. Other option could be self-hosted runners. Thoughts? |
This solves WebAssembly#236.
Per my comment in #347, I'm planning to work on this soonish. If we can't use a native runner for whatever reason, we can cross-compile, potentially. I'll look into it. |
According to GitHub docs, it appears that ARM based runners are only available for paying customers. Looking forward to having wasi-sdk on linux/arm64 though! |
Yeah, I noticed the documentation doesn't seem really clear on that...but I remember seeing the news article come out a while back about them releasing m1 runners free for open source projects...and this seems to indicate the same as well actions/runner-images#9254 |
Currently, the Makefile assumes the LLVM toolchain it builds can be executed natively to build `wasi-libc` etc., which isn't true when cross-compiling for another platform, but we can work around that by: 1. Building the native LLVM toolchain and using it to build everything else, as usual 2. Deleting that LLVM build and rebuilding (and reinstalling) it with `LLVM_CMAKE_FLAGS` set to cross compile 3. Rebuilding and reinstalling a cross-compiled `wasm-component-ld` 4. Building deb and tar files from the above Note that we now label the tarfiles `linux-amd64` and `linux-arm64`, respectively for clarity. The whole approach is a bit hacky, but GitHub is planning to roll out ARM64 runner support for open source projects later this year, at which point we can start building natively, so I don't think we need to invest a lot of effort into this. I've run CI in my fork and verified the artifact produced there works on my Ubuntu 24.04 ARM64 machine (Asahi Linux on an Apple M2 Pro). Note that I have not yet updated the `dockerbuild` CI step, so the `dist-ubuntu-bionic` artifacts do not yet include an ARM64 build; I'll experiment with that next. Fixes WebAssembly#236 Fixes WebAssembly#347 Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Currently, the Makefile assumes the LLVM toolchain it builds can be executed natively to build `wasi-libc` etc., which isn't true when cross-compiling for another platform, but we can work around that by: 1. Building the native LLVM toolchain and using it to build everything else, as usual 2. Deleting that LLVM build and rebuilding (and reinstalling) it with `LLVM_CMAKE_FLAGS` set to cross compile 3. Rebuilding and reinstalling a cross-compiled `wasm-component-ld` 4. Building deb and tar files from the above Note that we now label the tarfiles `linux-amd64` and `linux-arm64`, respectively for clarity. The whole approach is a bit hacky, but GitHub is planning to roll out ARM64 runner support for open source projects later this year, at which point we can start building natively, so I don't think we need to invest a lot of effort into this. I've run CI in my fork and verified the artifact produced there works on my Ubuntu 24.04 ARM64 machine (Asahi Linux on an Apple M2 Pro). Fixes WebAssembly#236 Fixes WebAssembly#347 Signed-off-by: Joel Dice <joel.dice@fermyon.com>
I believe this is done now in #429, so closing. |
I think an increasing number of us are running on Linux on Apple Silicon with Parallels in a VM, and support would be great. I can always build from source, but I would guess there will be plenty of others who will run into this.
There is already an issue for this on MacOS #221.
The text was updated successfully, but these errors were encountered: