Support for darwin-arm64
kingkong404 opened this issue · comments
Hey, are there plans to support Apple Silicon?
Yes. But we need support in rusty_v8 first: denoland/rusty_v8#520. To get that working, we need to be able to build and test macos ARM64 binaries on CI. So that means either using QEMU, or waiting for GitHub to support macOS arm64 native runners.
There is also a few bugs within the dependency tree that are also failing to build.
error: failed to run custom build command for `ring v0.16.15`
Caused by:
process didn't exit successfully: `/Users/dygear/deno/target/debug/build/ring-6754f2719fc74212/build-script-build` (exit code: 101)
[snip]
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:18:17: error: unexpected token in '.section' directive
.section .rodata
^
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:28:1: error: unknown directive
.hidden GFp_aes_hw_set_encrypt_key
^
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:29:1: error: unknown directive
.type GFp_aes_hw_set_encrypt_key,%function
^
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:161:1: error: unknown directive
.size GFp_aes_hw_set_encrypt_key,.-GFp_aes_hw_set_encrypt_key
^
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:163:1: error: unknown directive
.hidden GFp_aes_hw_encrypt
^
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:164:1: error: unknown directive
.type GFp_aes_hw_encrypt,%function
^
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:191:1: error: unknown directive
.size GFp_aes_hw_encrypt,.-GFp_aes_hw_encrypt
^
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:193:1: error: unknown directive
.hidden GFp_aes_hw_decrypt
^
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:194:1: error: unknown directive
.type GFp_aes_hw_decrypt,%function
^
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:221:1: error: unknown directive
.size GFp_aes_hw_decrypt,.-GFp_aes_hw_decrypt
^
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:223:1: error: unknown directive
.hidden GFp_aes_hw_ctr32_encrypt_blocks
^
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:224:1: error: unknown directive
.type GFp_aes_hw_ctr32_encrypt_blocks,%function
^
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:403:1: error: unknown directive
.size GFp_aes_hw_ctr32_encrypt_blocks,.-GFp_aes_hw_ctr32_encrypt_blocks
^
/Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:407:19: error: unexpected token in '.section' directive
.section .note.GNU-stack,"",%progbits
^
thread 'main' panicked at 'execution failed', /Users/dygear/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/build.rs:664:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed
So, we have a few mountains to climb first. But they are working on it! briansmith/ring#1063 and rust has to settle on a triple target for it as well rust-lang/rust#73628
When I download the latest x86 binary from here, everything run fine with rosetta2 👍. Waiting for a ARM64 native build, but all good in the meantime.
Once support is in place for Apple Silicon will it be possible to run on a ARM64 board like Raspberry Pi 4? Or will this require additional work?
@frankhale that is issue #1846, they are distinct issues.
It is not "sustainable" at the moment and still experimental so we will keep this issue open.
for anyone wanting apple-silicon support, simply install Rust then
cargo install deno --locked
on my m1 macbook air this results with Finished release [optimized] target(s) in 5m 27s and deno runs as expected
@jimmont I'm a Rust noob, I've been using cargo build --release and am curious why everyone keeps mentioning to use cargo install deno --locked. What is the difference?
Looks like that forces rust to ignore the network if it can and cherry pick the exact upstream version requested by the cargo toml lock file.
You can find more about that here. https://doc.rust-lang.org/cargo/commands/cargo-build.html#manifest-options
Great question!
Thank you @Dygear, I'll check out that doc you mentioned!!!
On https://github.com/denoland/deno/releases there is a deno-aarch64-apple-darwin.zip asset, so seems this can be closed right?
See #8346 (comment)
Any update on this? Are we waiting for github/roadmap#528 for a "more sustainable solution"?
Yes, right now it requires manual work on release from the maintainers to provide an M1 build.
We now have automated releases for apple silicon, so closing.