Building for arm64

[afinch7]

Builds for arm64 are now in CI, but are not ready for release. We still need to make some changes to make the tests work with this build. I managed to get deno to build for arm64 using the aarch64-unknown-linux-gnu target. Currently It doesn't execute successfully on a raspberry pi 3b+ running a preview image of debian buster arm64/aarch64. It gives me the following print out:

root@rpi3:~/deno-build# ./deno https://deno.land/welcome.ts
#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0xfffff58d4d10
==== C stack trace ===============================

    ./deno(+0x8ad5fc) [0xaaaaafc445fc]
    ./deno(+0x9dd72c) [0xaaaaafd7472c]
    ./deno(+0x8a9f10) [0xaaaaafc40f10]
    ./deno(+0x83aa08) [0xaaaaafbd1a08]
    ./deno(+0x69c070) [0xaaaaafa33070]
    ./deno(+0x7bdbb4) [0xaaaaafb54bb4]
    ./deno(+0x7bdb00) [0xaaaaafb54b00]
    ./deno(+0x7bc6bc) [0xaaaaafb536bc]
    ./deno(+0x7bd9f8) [0xaaaaafb549f8]
    ./deno(+0x7bbbb8) [0xaaaaafb52bb8]
    ./deno(+0x2165dc) [0xaaaaaf5ad5dc]
    ./deno(+0x7c0be4) [0xaaaaafb57be4]
    ./deno(+0x663f68) [0xaaaaaf9faf68]
    ./deno(+0x7c0124) [0xaaaaafb57124]
    ./deno(+0x1c8e80) [0xaaaaaf55fe80]
    ./deno(+0x1c8f68) [0xaaaaaf55ff68]
    ./deno(+0x1b3dec) [0xaaaaaf54adec]
    ./deno(+0xce2f0) [0xaaaaaf4652f0]
    ./deno(+0x112b78) [0xaaaaaf4a9b78]
    ./deno(+0x11ef74) [0xaaaaaf4b5f74]
    ./deno(+0xb80c38) [0xaaaaaff17c38]
    ./deno(+0xb8fcf4) [0xaaaaaff26cf4]
    ./deno(+0xb814ec) [0xaaaaaff184ec]
    ./deno(+0x112d50) [0xaaaaaf4a9d50]
    /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe4) [0xffff8644ed24]
    ./deno(+0xbae4c) [0xaaaaaf451e4c]

I opened up the executable with a arm compatible disassembler, and located the last call from within deno before failure, 0x1b3dec. It looks like this call occurs here https://github.com/denoland/deno/blob/b8a537d020f5e4495572daa4d8a59f51fa3b20d1/libdeno/api.cc#L54 This leads me to suspect an issue with loading the snapshot.

I managed to get this working successfully with the changes in [my forked branch](https://github.com/afinch7/deno/tree/arm-builds).

To replicate my arm64 build you will need docker installed. Then it should be as simple as:

1. Add the following options to .gn

target_cpu = "arm64"
v8_target_cpu = "arm64"

2. Add the following to Dockerfile in your deno repo root

FROM ubuntu:bionic

RUN apt update && apt install -y curl

RUN curl https://sh.rustup.rs -sSf | sh -s -- -y

RUN /root/.cargo/bin/rustup target add aarch64-unknown-linux-gnu

RUN echo "[target.aarch64-unknown-linux-gnu]\nlinker = \"aarch64-linux-gnu-gcc\"" > /root/.cargo/config

RUN apt install -y nodejs yarn python build-essential cmake make

RUN apt -yq --no-install-suggests --no-install-recommends install g++-aarch64-linux-gnu gcc-aarch64-linux-gnu g++-7-multilib libc6-arm64-cross

WORKDIR /deno

RUN echo "source $HOME/.cargo/env" > /root/.bash

CMD ["/bin/bash", "--init-file", "/root/.bash"]

3. Run docker build -f Dockerfile -t deno-arm64-build . && docker run -it -v "$PWD/:/deno" -u $(id -u root):$(id -g ${USER}) deno-arm64-build in your deno repo root. This should build a docker image with the required tools and drop you into a bash shell on said image with your deno repo mounted at /deno.
4. From this point you simply need to run cargo build --target=aarch64-unknown-linux-gnu --release
5. Once the build completes the executable should be located at target/aarch64-unknown-linux-gnu/release/deno

I wasn't able to get a build working with tools/build.py, since I couldn't find a way to specify a target for rust ~~it might be possible to use env vars like CC, AR, CFLAGS, etc. I might try that at some point, but I'm putting my efforts into figuring out if the snapshots are even being included in the build correctly right now.~~ I not sure what changed, but I can't get the build to work anymore with docker. I can still get this to work outside of docker though. I'm working on getting this into CI see #1887. The main problem with getting this into CI is how long it takes to build.

Edit: fixed some issues with the Dockerfile Edit: added the current user group to the docker run command so this doesn't break your repo as much Edit: my forked branch has modifications to make this work now

[afinch7]

@ry My guess at this point is that v8 snapshots are not independent of the binaries used to generate them. That would make since considering that the snapshots are generated by the compiler host using a native binary. Can you confirm this is the case with v8?

[ry]

@afinch7 I'll have to dig into this later when I have some time - but one random guess - try v8_multi_arch_build = true

[afinch7]

@ry Turns out I was right chromium has had a similar issue with cross compiled builds using snapshots. My plan at this point remove inclusion of compile time generated snapshots on cross compiled builds, and setup some logic to allow them to generate the snapshots during the first runtime(and store them on disk for next time). I would build on aarch64, but depot_tools doesn't seem to have a gn binary for aarch64. #1852

[ry]

basic arm support added in 8c7a12d1b258f0ef5ab27f49c424331d43e8d97f

[Trucoto]

I have a project where deno would fit perfectly, I made some tests on x86_64 and it works well, but I will need arm support in the future, so does this have a place in the roadmap? What is the current status? What does it mean "basic support"?

[kitsonk]

ARM64 support was reverted some time ago... re-opening.

[leolivier]

FYI, not sure if deno is using Travis CI in conjunction with github but Travis CI now supports multi arch including arm64, see https://docs.travis-ci.com/user/multi-cpu-architectures/ and you don't need to use qemu for that (as far as I understood, I didn't test it by myself)

[Dygear]

I've also had zero issues building an aarch64 build for the last couple of versions that I've tested. I'd be happy to donate a few Raspberry Pi 4 (8GB) to this project in order to make a stable release happen. Now that the Mac has released their ARM hardware, I can also build the same on there for that.

[kitsonk]

FYI, not sure if deno is using Travis CI in conjunction with github but Travis CI

We use GitHub Actions exclusively. We are working with GitHub on the potential of their ARM64 support.

I'd be happy to donate a few Raspberry Pi 4 (8GB) to this project in order to make a stable release happen.

That isn't necessary, and likely wouldn't solve the problem of integrating it reliably into a repeatable and supportable APIs.

[frankhale]

For those that may not know Deno builds easily on a Pi 4 without any modifications necessary. Takes about an hour on a non-overclocked Pi 4 with just a microSD card. Have fun!

[jimmont]

Echoing what frankhale mentioned, the Raspberry Pi OS 64bit-beta updated on the RPi4 8GB installs in about 1 hour with standard install and cargo install deno --locked, from there deno works as expected. (RPi3b gets stuck somewhere in my 2 attempts so-far, letting it run overnight, etc.) Haven't tried 32bit Raspberry Pi OS on this RPI4 device (yet).

[LukeChannings]

I have had some success building for ARM64 on GitHub Actions. It takes about 2 hours, compared with 20 minutes for AMD64.

https://github.com/LukeChannings/docker-deno/actions/runs/482795009

The process for this repo is:

• create a release named after the Deno version
• The GitHub Actions workflow downloads the source from Deno and compiles AMD64 natively, and ARM64 with QEMU using the ubuntu:18.04 image.
• It publishes the compiled binaries to the assets for the release for people to download
• The next step builds a Docker image that downloads the binaries and bundles the using a ubuntu:20.04 base image.

That last step is failing and I haven't had the time to finish it, but everything else works, and there's a published 1.6.3 image under lukechannings/deno:1.6.3 if anyone needs it.

I built this for another project I'm working on, and people seem to be running the ARM64 image on a Raspberry Pi 4 without problems.
https://github.com/LukeChannings/moviematch/issues/27

[frankhale]

@jimmont I made it almost the entire way through the building process on the RPi3B+ but I came to a point where it would lock up consistently. I'm guessing it's running out of memory? I was building it on Ubuntu Server 20.10 so the Pi would not be using much memory. I also made a 4 gb swap file which didn't seem to help.

[Dygear]

I'm willing to bet that you are running out of memory. Even on a Raspberry Pi 4 4GB, you need to use swap space (around 2GB) in order to compile correctly. I think one compile thread uses more than the 4GB boundary of a single application thread in the 32bit OS. So we are gonna have a hard time here. I've been using an 8GB Pi 4 and that just squeaks by. I'll try later tonight if an 8GB Pi can compile on the 32bit OS or and confirm if it's a memory boundary problem.

[frankhale]

Has anyone attempted a compile of 1.7.0 on a Pi 4? I did but I'm running into problems:

error: failed to add native library /home/ubuntu/code/deno/target/release/gn_out/obj/librusty_v8.a: file too small to be an archive

error: aborting due to previous error

error: could not compile `rusty_v8`

[LukeChannings]

There are no rusty_v8 aarch64 builds yet. See https://github.com/denoland/rusty_v8/pull/589

[lucacasonato]

You can try to build fully from scratch by setting the V8_FROM_SOURCE env var to 1. Note that this will take a very long time.

[frankhale]

I'm still getting the same problem and it doesn't look to be compiling anything extra. I even deleted the repository, recloned it and started over. Do I need to clone Deno in a special way to get the dependencies? I tried with --recurse-submodule but it's still not building anything extra.

[Dygear]

@LukeChannings @frankhale I'm using a Raspberry Pi 4 (8GB). After doing a git pull and cargo clean, interesting -- I'm having the same issue. Something has changed, I just don't know what. I checked out the 1.6.3 tag (git checkout tag/1.6.3), and rebuilt it. That worked fine. So ... Huh. /target/release/gn_out/obj/librusty_v8.a is missing, but only when checking out the 1.7.0 build of deno. After that successful build, I moved back to master and ran cargo build -vvvv again. I didn't clean the build tree at all, just let it run as before. I get this ...

   Compiling deno v1.7.0 (/home/pi/deno/cli)
     Running `CARGO=/home/pi/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/bin/cargo CARGO_CRATE_NAME=build_script_build CARGO_MANIFEST_DIR=/home/pi/deno/cli CARGO_PKG_AUTHORS='the Deno authors' CARGO_PKG_DESCRIPTION='Provides the deno executable' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE=MIT CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=deno CARGO_PKG_REPOSITORY='https://github.com/denoland/deno' CARGO_PKG_VERSION=1.7.0 CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_MINOR=7 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/home/pi/deno/target/debug/deps:/home/pi/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib:/home/pi/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib' rustc --crate-name build_script_build --edition=2018 cli/build.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=2c312aa0fc278040 -C extra-filename=-2c312aa0fc278040 --out-dir /home/pi/deno/target/debug/build/deno-2c312aa0fc278040 -C incremental=/home/pi/deno/target/debug/incremental -L dependency=/home/pi/deno/target/debug/deps --extern deno_core=/home/pi/deno/target/debug/deps/libdeno_core-5876bc3f001c0642.rlib --extern deno_fetch=/home/pi/deno/target/debug/deps/libdeno_fetch-5ee2c3da97fadb56.rlib --extern deno_web=/home/pi/deno/target/debug/deps/libdeno_web-dbe712886b8d3ff1.rlib --extern deno_websocket=/home/pi/deno/target/debug/deps/libdeno_websocket-506e36a3b620244c.rlib --extern regex=/home/pi/deno/target/debug/deps/libregex-71aa19e4b49148ed.rlib --extern serde=/home/pi/deno/target/debug/deps/libserde-2e6e5d81f6e8f076.rlib -L /home/pi/deno/target/debug/gn_out/obj -L native=/home/pi/deno/target/debug/build/ring-cdee82299e607e55/out`
     Running `/home/pi/deno/target/debug/build/deno_runtime-34d455a0ce716031/build-script-build`
[deno_runtime 0.7.0] cargo:rustc-env=TARGET=aarch64-unknown-linux-gnu
[deno_runtime 0.7.0] cargo:rustc-env=PROFILE=debug
error: failed to run custom build command for `deno_runtime v0.7.0 (/home/pi/deno/runtime)`

Caused by:
  process didn't exit successfully: `/home/pi/deno/target/debug/build/deno_runtime-34d455a0ce716031/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
  --- stdout
  cargo:rustc-env=TARGET=aarch64-unknown-linux-gnu
  cargo:rustc-env=PROFILE=debug
warning: build failed, waiting for other jobs to finish...

Try it again ...

       Fresh deno_fetch v0.20.0 (/home/pi/deno/op_crates/fetch)
   Compiling deno_runtime v0.7.0 (/home/pi/deno/runtime)
     Running `/home/pi/deno/target/debug/build/deno_runtime-34d455a0ce716031/build-script-build`
[deno_runtime 0.7.0] cargo:rustc-env=TARGET=aarch64-unknown-linux-gnu
[deno_runtime 0.7.0] cargo:rustc-env=PROFILE=debug
[deno_runtime 0.7.0] thread 'main' panicked at 'assertion failed: `(left == right)`
[deno_runtime 0.7.0]   left: `Some(0x558d0de540)`,
[deno_runtime 0.7.0]  right: `Some(0x558d10e3a0)`', /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0/src/scope.rs:1261:7
[deno_runtime 0.7.0] note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[deno_runtime 0.7.0] thread 'main' panicked at 'assertion failed: `(left == right)`
[deno_runtime 0.7.0]   left: `Some(0x558d0de540)`,
[deno_runtime 0.7.0]  right: `Some(0x558d10e3a0)`', /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0/src/scope.rs:1261:7
[deno_runtime 0.7.0] stack backtrace:
[deno_runtime 0.7.0]    0:       0x5559a438ac - std::backtrace_rs::backtrace::libunwind::trace::h0bf177acf051491e
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/../../backtrace/src/backtrace/libunwind.rs:96
[deno_runtime 0.7.0]    1:       0x5559a438ac - std::backtrace_rs::backtrace::trace_unsynchronized::h13e350691a2e9c8c
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/../../backtrace/src/backtrace/mod.rs:66
[deno_runtime 0.7.0]    2:       0x5559a438ac - std::sys_common::backtrace::_print_fmt::h01973b8b9262a455
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:79
[deno_runtime 0.7.0]    3:       0x5559a438ac - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::ha9097f32cb02a890
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:58
[deno_runtime 0.7.0]    4:       0x5559a59fcc - core::fmt::write::h09ec856f07455be4
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/fmt/mod.rs:1082
[deno_runtime 0.7.0]    5:       0x5559a41188 - std::io::Write::write_fmt::h28ee10a061406531
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/io/mod.rs:1514
[deno_runtime 0.7.0]    6:       0x5559a4584c - std::sys_common::backtrace::_print::hb27fc1a755c045cd
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:61
[deno_runtime 0.7.0]    7:       0x5559a4584c - std::sys_common::backtrace::print::h93f2dd83b4ec9f44
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:48
[deno_runtime 0.7.0]    8:       0x5559a4584c - std::panicking::default_hook::{{closure}}::h7fef7b2214a9650e
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:200
[deno_runtime 0.7.0]    9:       0x5559a45584 - std::panicking::default_hook::hd4f1663a72ba25b8
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:219
[deno_runtime 0.7.0]   10:       0x5559a45ef4 - std::panicking::rust_panic_with_hook::h3365a52210317c21
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:569
[deno_runtime 0.7.0]   11:       0x5559a45adc - std::panicking::begin_panic_handler::{{closure}}::h767810307287d8f2
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:476
[deno_runtime 0.7.0]   12:       0x5559a43d34 - std::sys_common::backtrace::__rust_end_short_backtrace::he4cf53edc973a6a9
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:153
[deno_runtime 0.7.0]   13:       0x5559a45aa4 - rust_begin_unwind
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:475
[deno_runtime 0.7.0]   14:       0x5559a45a60 - std::panicking::begin_panic_fmt::he8daa79f0eeee0d2
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:429
[deno_runtime 0.7.0]   15:       0x55584790e4 - rusty_v8::scope::data::ScopeData::try_activate_scope::h389194cb044c04ba
[deno_runtime 0.7.0]                                at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0/src/scope.rs:1261
[deno_runtime 0.7.0]   16:       0x55584790e4 - rusty_v8::scope::data::ScopeData::get_mut::h75398f215fc2770f
[deno_runtime 0.7.0]                                at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0/src/scope.rs:1248
[deno_runtime 0.7.0]   17:       0x555846c668 - <rusty_v8::scope::HandleScope<C> as core::ops::drop::Drop>::drop::h76c8dc9b5e1f1ed1
[deno_runtime 0.7.0]                                at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0/src/scope.rs:636
[deno_runtime 0.7.0]   18:       0x5558467528 - core::ptr::drop_in_place::h5019043c4c0a3232
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ptr/mod.rs:184
[deno_runtime 0.7.0]   19:       0x555842d78c - deno_core::runtime::JsRuntime::execute::h4bdf2102c1079225
[deno_runtime 0.7.0]                                at /home/pi/deno/core/runtime.rs:408
[deno_runtime 0.7.0]   20:       0x555842d62c - deno_core::runtime::JsRuntime::js_init::hb582601e0480991b
[deno_runtime 0.7.0]                                at /home/pi/deno/core/runtime.rs:340
[deno_runtime 0.7.0]   21:       0x555842ce7c - deno_core::runtime::JsRuntime::new::h2980e23a6f189701
[deno_runtime 0.7.0]                                at /home/pi/deno/core/runtime.rs:299
[deno_runtime 0.7.0]   22:       0x55583fe2c0 - build_script_build::create_runtime_snapshot::h8cb419e74d83d218
[deno_runtime 0.7.0]                                at /home/pi/deno/runtime/build.rs:43
[deno_runtime 0.7.0]   23:       0x55583fe6a0 - build_script_build::main::hba0a43c2be0e59f3
[deno_runtime 0.7.0]                                at /home/pi/deno/runtime/build.rs:67
[deno_runtime 0.7.0]   24:       0x5558401820 - core::ops::function::FnOnce::call_once::h0e4c609c7889b79a
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops/function.rs:227
[deno_runtime 0.7.0]   25:       0x55583ffd60 - std::sys_common::backtrace::__rust_begin_short_backtrace::h319d4e8ef7130d19
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:137
[deno_runtime 0.7.0]   26:       0x55584029a4 - std::rt::lang_start::{{closure}}::h1ae6dcd9d3c3f2d1
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/rt.rs:66
[deno_runtime 0.7.0]   27:       0x5559a461e0 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h374c3e02094e44c2
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops/function.rs:259
[deno_runtime 0.7.0]   28:       0x5559a461e0 - std::panicking::try::do_call::ha3ec3588007a4da2
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:373
[deno_runtime 0.7.0]   29:       0x5559a461e0 - std::panicking::try::h7d1b1365534463ec
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:337
[deno_runtime 0.7.0]   30:       0x5559a461e0 - std::panic::catch_unwind::he04a9b0c3dd8e3c1
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panic.rs:379
[deno_runtime 0.7.0]   31:       0x5559a461e0 - std::rt::lang_start_internal::h18550bd0c37e45d2
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/rt.rs:51
[deno_runtime 0.7.0]   32:       0x555840297c - std::rt::lang_start::h86cde3ab80c17d20
[deno_runtime 0.7.0]                                at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/rt.rs:65
[deno_runtime 0.7.0]   33:       0x55583fe870 - main
[deno_runtime 0.7.0]   34:       0x7f9032bd24 - __libc_start_main
[deno_runtime 0.7.0]   35:       0x55583fd99c - <unknown>
[deno_runtime 0.7.0] thread panicked while panicking. aborting.
error: failed to run custom build command for `deno_runtime v0.7.0 (/home/pi/deno/runtime)`

Caused by:
  process didn't exit successfully: `/home/pi/deno/target/debug/build/deno_runtime-34d455a0ce716031/build-script-build` (signal: 5, SIGTRAP: trace/breakpoint trap)
  --- stdout
  cargo:rustc-env=TARGET=aarch64-unknown-linux-gnu
  cargo:rustc-env=PROFILE=debug

  --- stderr
  thread 'main' panicked at 'assertion failed: `(left == right)`
    left: `Some(0x558d0de540)`,
   right: `Some(0x558d10e3a0)`', /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0/src/scope.rs:1261:7
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
  thread 'main' panicked at 'assertion failed: `(left == right)`
    left: `Some(0x558d0de540)`,
   right: `Some(0x558d10e3a0)`', /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0/src/scope.rs:1261:7
  stack backtrace:
     0:       0x5559a438ac - std::backtrace_rs::backtrace::libunwind::trace::h0bf177acf051491e
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/../../backtrace/src/backtrace/libunwind.rs:96
     1:       0x5559a438ac - std::backtrace_rs::backtrace::trace_unsynchronized::h13e350691a2e9c8c
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/../../backtrace/src/backtrace/mod.rs:66
     2:       0x5559a438ac - std::sys_common::backtrace::_print_fmt::h01973b8b9262a455
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:79
     3:       0x5559a438ac - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::ha9097f32cb02a890
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:58
     4:       0x5559a59fcc - core::fmt::write::h09ec856f07455be4
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/fmt/mod.rs:1082
     5:       0x5559a41188 - std::io::Write::write_fmt::h28ee10a061406531
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/io/mod.rs:1514
     6:       0x5559a4584c - std::sys_common::backtrace::_print::hb27fc1a755c045cd
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:61
     7:       0x5559a4584c - std::sys_common::backtrace::print::h93f2dd83b4ec9f44
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:48
     8:       0x5559a4584c - std::panicking::default_hook::{{closure}}::h7fef7b2214a9650e
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:200
     9:       0x5559a45584 - std::panicking::default_hook::hd4f1663a72ba25b8
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:219
    10:       0x5559a45ef4 - std::panicking::rust_panic_with_hook::h3365a52210317c21
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:569
    11:       0x5559a45adc - std::panicking::begin_panic_handler::{{closure}}::h767810307287d8f2
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:476
    12:       0x5559a43d34 - std::sys_common::backtrace::__rust_end_short_backtrace::he4cf53edc973a6a9
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:153
    13:       0x5559a45aa4 - rust_begin_unwind
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:475
    14:       0x5559a45a60 - std::panicking::begin_panic_fmt::he8daa79f0eeee0d2
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:429
    15:       0x55584790e4 - rusty_v8::scope::data::ScopeData::try_activate_scope::h389194cb044c04ba
                                 at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0/src/scope.rs:1261
    16:       0x55584790e4 - rusty_v8::scope::data::ScopeData::get_mut::h75398f215fc2770f
                                 at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0/src/scope.rs:1248
    17:       0x555846c668 - <rusty_v8::scope::HandleScope<C> as core::ops::drop::Drop>::drop::h76c8dc9b5e1f1ed1
                                 at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0/src/scope.rs:636
    18:       0x5558467528 - core::ptr::drop_in_place::h5019043c4c0a3232
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ptr/mod.rs:184
    19:       0x555842d78c - deno_core::runtime::JsRuntime::execute::h4bdf2102c1079225
                                 at /home/pi/deno/core/runtime.rs:408
    20:       0x555842d62c - deno_core::runtime::JsRuntime::js_init::hb582601e0480991b
                                 at /home/pi/deno/core/runtime.rs:340
    21:       0x555842ce7c - deno_core::runtime::JsRuntime::new::h2980e23a6f189701
                                 at /home/pi/deno/core/runtime.rs:299
    22:       0x55583fe2c0 - build_script_build::create_runtime_snapshot::h8cb419e74d83d218
                                 at /home/pi/deno/runtime/build.rs:43
    23:       0x55583fe6a0 - build_script_build::main::hba0a43c2be0e59f3
                                 at /home/pi/deno/runtime/build.rs:67
    24:       0x5558401820 - core::ops::function::FnOnce::call_once::h0e4c609c7889b79a
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops/function.rs:227
    25:       0x55583ffd60 - std::sys_common::backtrace::__rust_begin_short_backtrace::h319d4e8ef7130d19
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:137
    26:       0x55584029a4 - std::rt::lang_start::{{closure}}::h1ae6dcd9d3c3f2d1
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/rt.rs:66
    27:       0x5559a461e0 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h374c3e02094e44c2
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops/function.rs:259
    28:       0x5559a461e0 - std::panicking::try::do_call::ha3ec3588007a4da2
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:373
    29:       0x5559a461e0 - std::panicking::try::h7d1b1365534463ec
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:337
    30:       0x5559a461e0 - std::panic::catch_unwind::he04a9b0c3dd8e3c1
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panic.rs:379
    31:       0x5559a461e0 - std::rt::lang_start_internal::h18550bd0c37e45d2
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/rt.rs:51
    32:       0x555840297c - std::rt::lang_start::h86cde3ab80c17d20
                                 at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/rt.rs:65
    33:       0x55583fe870 - main
    34:       0x7f9032bd24 - __libc_start_main
    35:       0x55583fd99c - <unknown>
  thread panicked while panicking. aborting.
warning: build failed, waiting for other jobs to finish...
error: build failed

As I don't know what is going on anymore I went back to the start. git clone --recurse-submodules https://github.com/denoland/deno.git ~/deno_v8 As I don't want to overwrite my actual ~/deno directory, so I put this in ~/deno_v8 to take @LukeChannings' advise and build with V8. cd ~/deno_v8 once it's all checked out. And run V8_FROM_SOURCE=1 cargo build -vv. Luke said this is going to take a long time, so I'm going to sleep. I'll check back once I wake up. But it seems that the problem is there for sure.

[frankhale]

Thanks @Dygear for the extra confirmation and detailed information. I am also using an 8gb Pi 4 but my knowledge of the toolchain is not nearly as detailed as yours. I cloned the repo like you did and also set V8_FROM_SOURCE but it did not take a while to build, the build process was exactly the same and the failure was the same for me. This got me thinking that there must be some other steps that people just implicitly know to do that was not conveyed above but I don't know.

[Dygear]

I'm honestly not sure where the problem is. I don't believe the build V8 from source option has ever worked for me on a Raspberry Pi platform. It's possible, the the pre-compiled V8 code simply doesn't have all of the files we need for the ARM64 process inside of our Raspberry Pi 64-bit OS. It certainly helps to link to these already compiled object files, but I think a few are missing. I just don't really know where the compile pulls them from or expects to find them for me to be able to trouble shoot this correctly. I'm going to read the source code and hopefully I can figure it out.

@LukeChannings The compile V8 option actually doesn't work either.

   Compiling rustyline v7.1.0
     Running `CARGO=/home/pi/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/bin/cargo CARGO_CRATE_NAME=rustyline CARGO_MANIFEST_DIR=/home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rustyline-7.1.0 CARGO_PKG_AUTHORS='Katsu Kawakami <[email protected]>' CARGO_PKG_DESCRIPTION='Rustyline, a readline implementation based on Antirez'\''s Linenoise' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE=MIT CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=rustyline CARGO_PKG_REPOSITORY='https://github.com/kkawakam/rustyline' CARGO_PKG_VERSION=7.1.0 CARGO_PKG_VERSION_MAJOR=7 CARGO_PKG_VERSION_MINOR=1 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/home/pi/deno_v8/target/debug/deps:/home/pi/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib:/home/pi/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib' rustc --crate-name rustyline --edition=2018 /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rustyline-7.1.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=a63972f04dd793a5 -C extra-filename=-a63972f04dd793a5 --out-dir /home/pi/deno_v8/target/debug/deps -L dependency=/home/pi/deno_v8/target/debug/deps --extern bitflags=/home/pi/deno_v8/target/debug/deps/libbitflags-8697a9bfe9f801d9.rmeta --extern cfg_if=/home/pi/deno_v8/target/debug/deps/libcfg_if-f839896df4fc84b3.rmeta --extern fs2=/home/pi/deno_v8/target/debug/deps/libfs2-9436ff614a97209b.rmeta --extern libc=/home/pi/deno_v8/target/debug/deps/liblibc-8a7be3f7c7d71dd5.rmeta --extern log=/home/pi/deno_v8/target/debug/deps/liblog-3d420c83767f3cbd.rmeta --extern memchr=/home/pi/deno_v8/target/debug/deps/libmemchr-88d44ab3a3ad53b8.rmeta --extern nix=/home/pi/deno_v8/target/debug/deps/libnix-d06e9adb446c0b6b.rmeta --extern unicode_segmentation=/home/pi/deno_v8/target/debug/deps/libunicode_segmentation-0eb7ef3dc88bb3d6.rmeta --extern unicode_width=/home/pi/deno_v8/target/debug/deps/libunicode_width-fbbe897f9c536b45.rmeta --extern utf8parse=/home/pi/deno_v8/target/debug/deps/libutf8parse-501eca5af2b9d42a.rmeta --cap-lints warn`
[rusty_v8 0.16.0] Downloading https://commondatastorage.googleapis.com/chromium-browser-clang/Linux_x64/clang-llvmorg-12-init-11060-g118c3f3c-1.tgz .......... Done.
[rusty_v8 0.16.0] cargo:warning=Not using sccache or ccache
[rusty_v8 0.16.0] The current directory is /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0
[rusty_v8 0.16.0] gn gen --root=/home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0 /home/pi/deno_v8/target/debug/gn_out
[rusty_v8 0.16.0] running: "/home/pi/deno_v8/target/debug/ninja_gn_binaries-20210101/linux64/gn" "--root=/home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0" "gen" "/home/pi/deno_v8/target/debug/gn_out" "--args=is_debug=true clang_base_path=\"/home/pi/deno_v8/target/debug/clang\""
[rusty_v8 0.16.0] /home/pi/deno_v8/target/debug/ninja_gn_binaries-20210101/linux64/gn: 1: /home/pi/deno_v8/target/debug/ninja_gn_binaries-20210101/linux64/gn: t:t:Q�td��: not found
[rusty_v8 0.16.0] /home/pi/deno_v8/target/debug/ninja_gn_binaries-20210101/linux64/gn: 2: /home/pi/deno_v8/target/debug/ninja_gn_binaries-20210101/linux64/gn: Syntax error: ")" unexpected
[rusty_v8 0.16.0] thread 'main' panicked at '
[rusty_v8 0.16.0] command did not execute successfully, got: exit code: 2
[rusty_v8 0.16.0] 
[rusty_v8 0.16.0] build script failed, must exit now', /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo_gn-0.0.15/src/lib.rs:203:3
[rusty_v8 0.16.0] note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[rusty_v8 0.16.0] /home/pi/deno_v8/target/debug/ninja_gn_binaries-20210101/linux64/gn: 1: /home/pi/deno_v8/target/debug/ninja_gn_binaries-20210101/linux64/gn: �A: not found
[rusty_v8 0.16.0] /home/pi/deno_v8/target/debug/ninja_gn_binaries-20210101/linux64/gn: 1: /home/pi/deno_v8/target/debug/ninja_gn_binaries-20210101/linux64/gn: ELF: not found
The following warnings were emitted during compilation:

warning: Not using sccache or ccache

error: failed to run custom build command for `rusty_v8 v0.16.0`

Caused by:
  process didn't exit successfully: `/home/pi/deno_v8/target/debug/build/rusty_v8-11a5972bc80a798f/build-script-build` (exit code: 101)
  --- stdout
  Downloading https://github.com/denoland/ninja_gn_binaries/archive/20210101.tar.gz... Done.
  using Chromiums clang
  clang_base_path /home/pi/deno_v8/target/debug/clang
  Downloading https://commondatastorage.googleapis.com/chromium-browser-clang/Linux_x64/clang-llvmorg-12-init-11060-g118c3f3c-1.tgz .......... Done.
  cargo:warning=Not using sccache or ccache
  The current directory is /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0
  gn gen --root=/home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0 /home/pi/deno_v8/target/debug/gn_out
  running: "/home/pi/deno_v8/target/debug/ninja_gn_binaries-20210101/linux64/gn" "--root=/home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.16.0" "gen" "/home/pi/deno_v8/target/debug/gn_out" "--args=is_debug=true clang_base_path=\"/home/pi/deno_v8/target/debug/clang\""
warning: build failed, waiting for other jobs to finish...
error: build failed

[frankhale]

Has anyone tried to build 1.7.1 yet to see if this has been resolved? If not I'll give it a shot today.

[LukeChannings]

rusty_v8 wasn't updated in 1.7.1, so no change.

[Dygear]

I skipped a couple of builds, because I was very busy these last few days with work work. I'm currently working on building 1.7.4 with the latest stable version of rust (1.50.0) that was also current at the time of release for Deno 1.7.4. As it says in the documentation you do need a progressively current build of rust in order to compile. Trying to build Deno 1.7.4 with 1.47 of rust didn't work (so maybe that's the reason why.). It complained about there not being a valid artifact for v8_rust. So, I'm hoping that using the new version will fix that.

error: failed to add native library /home/pi/deno/target/release/gn_out/obj/librusty_v8.a: file too small to be an archive

error: aborting due to previous error

error: could not compile `rusty_v8`

Keep getting this error tho. So Deno is still broken on the stable-aarch64-unknown-linux-gnu triple target.

[konall]

I'm quite new to this project and not overly familiar with the nuances of cross-compiling so apologies if this is irrelevant to the issue at hand, but I was able to put together ~~Dockerfiles~~ (EDIT: builds fine but crashes at runtime, so in fact only works fully for x86_64 targets) to build both rusty_v8 and deno for arm architectures (desktop + mobile) from my machine in case they're of any use.

I don't have an arm machine on hand to verify 100% that there aren't any weird issues with the results, but the build process was completely smooth and I have fully verified that equivalent builds for x86_64 desktop + mobile targets have produced the desired results (the successful arm builds were basically as simple as swapping out the occurrences of "x86_64" with "arm64"/"aarch64")

[LukeChannings]

@konall

I tried this route myself and found that whilst it compiled, it would crash at runtime on the Pi.

https://github.com/denoland/deno/issues/4862#issuecomment-711110480

The cross compile situation is very complicated. It all revolves around snapshots. When v8 loads Javascript code into memory it essentially compiles it to bytecode(bit of a simplification here) hence v8 being a JIT compiler. On a x86 platform running a native executable this means that the bytecode is x86 bytecode. When we create a snapshot of v8 state it mostly includes this bytecode. If we are cross compiling this snapshot is generated by running a native executable ('build.rs') thus the snapshot generated is native to the compiler host and is not compatible with the platform we are compiling for. If we can either find a way to execute a arm native version of the snapshot generator at compile time or disable snapshots for cross compiles(my previous solution), we should be able to cross compile for arm64.

I'll compile your Dockerfile and test anyway, just in case.

Update: I compiled it and tested it on a Pi 4 and it crashes when running any JS. I tried patching cli/tsc.rs's compiler_snapshot() to return Option<Snapshot> and updated the call sites appropriately, which compiles, but Deno still crashes with an unhelpful error (built for debug too):

./deno run https://deno.land/std/examples/welcome.ts

#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0xffffdc9ae590
==== C stack trace ===============================

    ./deno(+0xf8ccf8) [0xaaaabe32dcf8]
    ./deno(+0x93ac74) [0xaaaabdcdbc74]
    ./deno(+0xf8921c) [0xaaaabe32a21c]
    ./deno(+0xcc46ec) [0xaaaabe0656ec]
    ./deno(+0x103ff8c) [0xaaaabe3e0f8c]
    ./deno(+0xc6f6fc) [0xaaaabe0106fc]
    ./deno(+0xc6d64c) [0xaaaabe00e64c]
    ./deno(+0xc7021c) [0xaaaabe01121c]
    ./deno(+0xc6d300) [0xaaaabe00e300]
    ./deno(+0xa0da68) [0xaaaabddaea68]
    ./deno(+0xc7abe0) [0xaaaabe01bbe0]
    ./deno(+0x9c20a0) [0xaaaabdd630a0]
    ./deno(+0x9c240c) [0xaaaabdd6340c]
    ./deno(+0xc79064) [0xaaaabe01a064]
    ./deno(+0x95ab08) [0xaaaabdcfbb08]
    ./deno(+0x95ac80) [0xaaaabdcfbc80]
    ./deno(+0x3e694c) [0xaaaabd78794c]
    ./deno(+0x555348) [0xaaaabd8f6348]
    ./deno(+0x3894f0) [0xaaaabd72a4f0]
    ./deno(+0x31d43c) [0xaaaabd6be43c]
    ./deno(+0x4cc880) [0xaaaabd86d880]
    ./deno(+0x393820) [0xaaaabd734820]
    ./deno(+0x2389a4) [0xaaaabd5d99a4]
    ./deno(+0x39d1b8) [0xaaaabd73e1b8]
    /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe8) [0xffffba386090]
    ./deno(+0x1eef7c) [0xaaaabd58ff7c]
Trace/breakpoint trap (core dumped)

I'm not sure cross-compiling will be an option for some time.

[konall]

@LukeChannings

Ah, I suspected it couldn't be so simple! Excuse my ignorance, but if I wanted to do some build experiments does your linked comment imply that I'd have to dust off my Pi to perform any worthwhile testing or would an arm64 docker image + qemu combo suffice to circumvent the pitfalls suffered by cross-compilation?

[LukeChannings]

@konall

QEMU avoids the pitfalls certainly, but can be very slow. I have a project that uses GitHub Actions to compile a Deno binary and a Docker image here, but since rusty_v8 has been having problems with aarch64 builds it's stuck on 1.6.3.

It should be possible to cross-compile rusty_v8 and pass in the output to a QEMU deno build, that way the rusty_v8 build can go full speed.

[LukeChannings]

Okay, so...

• I've documented current state of affairs with regards to Deno and ARM support
• I have aarch64 builds for rusty_v8 in a fork, it seems the issues around sccache are only affecting the denoland/rusty_v8 repo.
• There is an ARM64 binary for the latest version of Deno (1.7.4), and I will be able to keep it up-to-date now that I've rectified the rusty_v8 issue.
• There is a multi-arch (x86_64 & aarch64) Docker image published to lukechannings/deno (Ubuntu based)

The full source and instructions on how to reproduce the binary and docker images can be found here, and you should be able to see the workflow logs here

[Dygear]

@LukeChannings Thank you for the writeup and double thank you for the section for people that don't want to run docker. Looking at the actions information, we are going to have to build from your source code until such a time your changes land in rusty_v8. Is there a PR somewhere for this that we can also follow? Thank you again for pushing this forward, it was way, way, way over my head.

[frankhale]

Thank you @LukeChannings for taking time to figure this out. Thank you also for a compiled binary of Deno 1.7.4 for ARM64!!!!!

[ry]

@LukeChannings Nice work! Let's try to land your changes upstream in rusty_v8. Would you mind submitting a patch?

[LukeChannings]

@ry Thanks. I've made a PR #628, but as I've explained in the PR I'm not confident it'll work, and suspect the issue is with denoland/rusty_v8's cache.

I noticed that you changed the cache key in your PR, and in my mind that aught to have fixed it. I may be out of my depth.

[Dygear]

Just pulled and tried to compile 1.7.5.

     Running `/home/pi/deno/target/debug/build/rusty_v8-f1a9b64f9e208dc4/build-script-build`
[rusty_v8 0.19.0] download lockfile: "/home/pi/deno/target/debug/build/lib_download.fslock"
[rusty_v8 0.19.0] static lib URL: https://github.com/denoland/rusty_v8/releases/download/v0.19.0/librusty_v8_debug_aarch64-unknown-linux-gnu.a
[rusty_v8 0.19.0] cargo:rustc-link-search=/home/pi/deno/target/debug/gn_out/obj
[rusty_v8 0.19.0] Downloading https://github.com/denoland/rusty_v8/releases/download/v0.19.0/librusty_v8_debug_aarch64-unknown-linux-gnu.a
[rusty_v8 0.19.0] Downloading https://github.com/denoland/rusty_v8/releases/download/v0.19.0/librusty_v8_debug_aarch64-unknown-linux-gnu.a...
[rusty_v8 0.19.0] HTTP Error 404: Not Found
[rusty_v8 0.19.0] Traceback (most recent call last):
[rusty_v8 0.19.0]   File "./tools/download_file.py", line 64, in <module>
[rusty_v8 0.19.0]     sys.exit(main())
[rusty_v8 0.19.0]   File "./tools/download_file.py", line 59, in main
[rusty_v8 0.19.0]     DownloadUrl(args.url, f)
[rusty_v8 0.19.0]   File "./tools/download_file.py", line 45, in DownloadUrl
[rusty_v8 0.19.0]     raise e
[rusty_v8 0.19.0] urllib2.HTTPError: HTTP Error 404: Not Found
[rusty_v8 0.19.0] Python downloader failed, trying with curl.
[rusty_v8 0.19.0] cargo:rustc-link-lib=static=rusty_v8

Followed by our old nemesis ...

error: failed to add native library /home/pi/deno/target/debug/gn_out/obj/librusty_v8.a: file too small to be an archive

error: aborting due to previous error

error: could not compile `rusty_v8`

Caused by:
  process didn't exit successfully: `CARGO=/home/pi/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/bin/cargo CARGO_CRATE_NAME=rusty_v8 CARGO_MANIFEST_DIR=/home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.19.0 CARGO_PKG_AUTHORS='the Deno authors' CARGO_PKG_DESCRIPTION='Rust bindings to V8' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE=MIT CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=rusty_v8 CARGO_PKG_REPOSITORY='https://github.com/denoland/rusty_v8' CARGO_PKG_VERSION=0.19.0 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=19 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/home/pi/deno/target/debug/deps:/home/pi/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib:/home/pi/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib' OUT_DIR=/home/pi/deno/target/debug/build/rusty_v8-06cbb029cde3ca97/out rustc --crate-name rusty_v8 --edition=2018 /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.19.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=6b7585f3e8fbc6cb -C extra-filename=-6b7585f3e8fbc6cb --out-dir /home/pi/deno/target/debug/deps -L dependency=/home/pi/deno/target/debug/deps --extern bitflags=/home/pi/deno/target/debug/deps/libbitflags-108c0771505bba5a.rmeta --extern lazy_static=/home/pi/deno/target/debug/deps/liblazy_static-a7fd64e1b486335c.rmeta --extern libc=/home/pi/deno/target/debug/deps/liblibc-a4dc91e2dbc420fd.rmeta --cap-lints warn -L /home/pi/deno/target/debug/gn_out/obj -l static=rusty_v8` (exit code: 1)
warning: build failed, waiting for other jobs to finish...
error: build failed

This is Raspberry Pi OS 64 bit as I may have mentioned before running on a Raspberry Pi 4 8GB system.

[LukeChannings]

@Dygear

rusty_v8 doesn't have an archive for v0.19.0, but you can download it here

To fix your compilation error, run:

cd /home/pi/deno
mkdir -p target/{,aarch64-unknown-linux-gnu}/release/gn_out/obj
curl -fL "https://github.com/LukeChannings/rusty_v8/releases/download/v0.19.0/librusty_v8_release_aarch64-unknown-linux-gnu.a" -o target/release/gn_out/obj/librusty_v8.a
cp target/release/gn_out/obj/librusty_v8.a target/aarch64-unknown-linux-gnu/release/gn_out/obj/librusty_v8.a

(I don't know if it's supposed to be in target/release/gn_out/obj/librusty_v8.a or target/aarch64-unknown-linux-gnu/release/gn_out/obj/librusty_v8.a, and the build takes so long that I just copied it into both places. It's a bit of a superstition for me at this point...

Then re-run cargo build.

You can also just download the arm64 binary:

curl -OL https://github.com/LukeChannings/docker-deno/releases/download/v1.7.5/deno-linux-arm64.zip
unzip deno-linux-arm64.zip
./deno run https://deno.land/std/examples/welcome.ts

[Dygear]

curl -fL "https://github.com/LukeChannings/rusty_v8/releases/download/v0.19.0/librusty_v8_release_aarch64-unknown-linux-gnu.a" -o target/debug/gn_out/obj/librusty_v8.a

As I was building a debug target as well.

Steps to successful arm64 build on Raspberry Pi 64bit OS.

cd ~
git clone --recurse-submodules https://github.com/denoland/deno.git
cd deno
mkdir -p target/{,aarch64-unknown-linux-gnu}/release/gn_out/obj
curl -fL "https://github.com/LukeChannings/rusty_v8/releases/download/v0.19.0/librusty_v8_release_aarch64-unknown-linux-gnu.a" -o target/release/gn_out/obj/librusty_v8.a
curl -fL "https://github.com/LukeChannings/rusty_v8/releases/download/v0.19.0/librusty_v8_release_aarch64-unknown-linux-gnu.a" -o target/debug/gn_out/obj/librusty_v8.a
cp target/release/gn_out/obj/librusty_v8.a target/aarch64-unknown-linux-gnu/release/gn_out/obj/librusty_v8.a
cargo -vv build
cargo -vv build --release

You might want to also link Deno into your path from the build directory. ... ln -s /home/pi/deno/target/release/deno /usr/bin/deno But it runs after you do that!

./deno run https://deno.land/std/examples/welcome.ts

@ry Looks like the source tree still compiles a v1.7.4 tagged artifact. But everything runs!

[Dygear]

Just an FYI, v1.8.0 compiles on Raspberry Pi OS 64bit without issue and without having to pull a rusty_v8 precompiled artifact.

[EDIT]

I wasn't exactly right. You do need to change the swap size -- even on the 8GB Raspberry Pi. I added 2GB to swap and it takes 38 minutes build (in release mode) just the deno binary. The memory usage gets to around 8.5GB total. Yikes.

[LukeChannings]

@Dygear Yep, the RAM increase has made it impossible to compile on GitHub Actions via QEMU. I've resorted to setting up a Linux VM on my M1 MBA and registering it as a GitHub Actions runner, which seems to be working OK so far.

(FYI, It compiles in 9.5 minutes on an M1 MBA in a VM with 4 cores and 8GB RAM, not too shabby)

[osddeitf]

I wonder why deno-arch64-unknown-linux-gnu.zip has not shown up on the Release page yet. There're only the followings:

• deno-aarch64-apple-darwin.zip
• deno-x86_64-apple-darwin.zip
• deno-x86_64-pc-windows-msvc.zip
• deno-x86_64-unknown-linux-gnu.zip

As far as I know:

• from Rust 1.49.0 (Dec 31, 2020), there's tier 1 support for aarch64-unknown-linux-gnu target, which is guaranteed to work.

  The Rust project builds official binary releases for each tier 1 target, and automated testing ensures that each tier 1 target builds and passes tests after each change

  Though, aarch64-apple-darwin target is tier 2 support, guaranteed to build, but not tested.

• There's librusty_v8_release_aarch64-unknown-linux-gnu.a from rusty_v8 release from v0.20.0 (Feb 26).

[crowlKats]

Because there is no GitHub linux aarch64 runners

[osddeitf]

so rusty_v8 is cross-compiled?

[lucacasonato]

Yes, but the way we cross compile it does not work for Deno CLI.

[crowlKats]

For the people in need for aarch64 linux binaries, I do have some over at https://deno.toaxl.com/. These are NOT official in any way, and i am not a maintainer, just an active contributor, so you would need to trust me.

[osddeitf]

Thanks, it took me nearly 10000 seconds to build using Docker cross-platform image build.

[noxifoxi]

For the people in need for aarch64 linux binaries, I do have some over at https://deno.toaxl.com/. These are NOT official in any way, and i am not a maintainer, just an active contributor, so you would need to trust me.

For me these builds do not work on debian (armbian) on my rockpi4. The program stopped on the error: ./deno: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./deno) because 2.31 is the latest version in every debian distribution so far.

However, the builds from https://github.com/LukeChannings/deno-arm64 just work fine for me.

[jerrygreen]

For the people in need for aarch64 linux binaries, I do have some over at https://deno.toaxl.com/. These are NOT official in any way, and i am not a maintainer, just an active contributor, so you would need to trust me.

Doesn't aarch64 run official deno executable? I mean, they both x64, shouldn't they be compatible? (Unlike x32)

Anyways, I tried your most recent executable (https://deno.toaxl.com/v1.9.2/) on my Raspberry Pi 4 (8 gb), just in case... But of course it doesn't work, the same way doesn't work the official build:

cannot execute binary file: Exec format error

I'd like someone to build for armv7l now, for 32 bit 😄

[crowlKats]

@JerryGreen There are currently no 32bit deno executables. see https://github.com/denoland/deno/issues/2295

Doesn't aarch64 run official deno executable?

no. arm and x86 are inherently different systems. you cant run executables for one on the other.

[jerrygreen]

Just made deno work on my Raspberry Pi 4 (8 gb) 🙂 Here's how:

I installed Ubuntu Server (64-bit) for Raspberry Pi (using Raspberry Imager), which is aarch64:

$ uname -m
aarch64

Then installed deno for aarch64, built by @LukeChannings (thx btw), under default ubuntu user:

curl -LJO https://github.com/LukeChannings/deno-arm64/releases/download/v1.12.1/deno-linux-arm64.zip
mkdir -p ~/.deno/bin
unzip deno-linux-arm64.zip -d ~/.deno/bin
echo $'export DENO_INSTALL="/home/ubuntu/.deno"\nexport PATH="$DENO_INSTALL/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
rm deno-linux-arm64.zip

Then you can finally run deno and see the interactive deno shell:

$ deno
Deno 1.12.1
exit using ctrl+d or close()
>

I kinda liked that Raspberry is 32-bit, means low-powered, potentially less heat, etc. That is unfortunate there's no 32-bit build:

• https://github.com/denoland/deno/issues/2295

Now I just have to be a bit careful about the heat, because it doesn't have a fan 🙂 If anything, here's little snippet I made to gradually logging the temperature:

while true; do echo $(date) - $(bc <<< "scale=1; $(cat /sys/class/thermal/thermal_zone0/temp) / 1000")\'C; sleep 30; done

Which logs something like this:

Thu Jul 22 11:52:02 UTC 2021 - 53.0'C
Thu Jul 22 11:52:32 UTC 2021 - 53.0'C
Thu Jul 22 11:53:02 UTC 2021 - 52.0'C
Thu Jul 22 11:53:32 UTC 2021 - 53.5'C
Thu Jul 22 11:54:02 UTC 2021 - 53.0'C
Thu Jul 22 11:54:32 UTC 2021 - 53.0'C
Thu Jul 22 11:55:02 UTC 2021 - 53.0'C

Stock 32-bit Raspbian had some average of 50.5'C when calm Newly installed 64-bit Ubuntu Server has 53.5'C when calm (maybe environment got a bit warmer idk, or that's just OS) Anyway, Raspberry supports temperature up to 82.0'C it seems, people say, - before it starts throttling. When I tried building deno sources using Raspbian, it temporarily got up to 72.0'C within 10 minutes, but then the build failed, and it got back to normal after another 10 minutes. And I didn't figure out how to build for 32-bit... I hope this version will be available somewhat later, and aarch64 will be also officially supported, too. For now, let's tinker with what we have 🙂

[runlevel5]

Since we have officially supported darwin-arm64, wondering if we could publish the binary for linux-arm64 too? It's just natural that many devs use macOS for dev then deploy to ARM-based prod running Linux.

[crowlKats]

darwin-arm64 builds are made manually. technically the same could be done for linux-arm64, but most linux-arm64 devices arent exactly the most powerful, as building deno on a rpi can take up to 80 minutes, which isnt exactly a viable solution

[runlevel5]

@crowlKats the MacMini or MBP M1 are the best Linux arm64 box on the market atm. Devs could run UTM (QEMU frontend) to run Linux ARM64 VM

[kitsonk]

There are lots of things the devs can do. We have priorities though that may not align to each individuals priorities.

[LukeChannings]

Nobody is owed Linux ARM64 binaries, it's not straightforward to provide them, and like @kitsonk said, there are more important things that the Deno team are working on.

If you really need Linux ARM64 builds or multi-arch Docker images you can find them at lukechannings/deno-arm64. I have been compiling these binaries since v1.6.3 and the compilation process is open source.

I'm using a github actions runner in Docker on an M1 MacBook Air, and you should be able to see the compilation logs here.

Compiling on an M1 Mac takes 15-30 minutes, vs several hours on a Pi 4 (with at least 4GB RAM).

Looking through Github actions environment issues, it doesn't look like GitHub are planning to add ARM64 environments any time soon.

[noxifoxi]

I have modified the official install script to simplify the install and upgrade process with your (@LukeChannings) awesomely provided builds - initially solely for me, but then thought it might be useful for everyone else in need of these builds: noxifoxi/deno_install-arm64

[06kellyjac]

If you really needed compiled aarch64-linux binaries you could give the nix builds a go The stable and unstable channels should have binaries in the cache

$ deno eval "Deno.run({cmd:['uname','-sm']})"
deno: command not found

$ nix-env -i deno
installing 'deno-1.14.3'

$ deno eval "Deno.run({cmd:['uname','-sm']})"
Linux aarch64

Only thing to be aware of is deno compile will be linking against the nix store rather than /lib like normal

$ deno compile tmp.ts
Check file:///root/tmp.ts
Bundle file:///root/tmp.ts
Compile file:///root/tmp.ts
Emit tmp

$ ldd tmp
	linux-vdso.so.1 (0x0000007fa295e000)
	libdl.so.2 => /nix/store/34k9b4lsmr7mcmykvbmwjazydwnfkckk-glibc-2.33-50/lib/libdl.so.2 (0x0000007f9f4d6000)
	libgcc_s.so.1 => /nix/store/34k9b4lsmr7mcmykvbmwjazydwnfkckk-glibc-2.33-50/lib/libgcc_s.so.1 (0x0000007f9f4b1000)
	libpthread.so.0 => /nix/store/34k9b4lsmr7mcmykvbmwjazydwnfkckk-glibc-2.33-50/lib/libpthread.so.0 (0x0000007f9f483000)
	libm.so.6 => /nix/store/34k9b4lsmr7mcmykvbmwjazydwnfkckk-glibc-2.33-50/lib/libm.so.6 (0x0000007f9f3da000)
	libc.so.6 => /nix/store/34k9b4lsmr7mcmykvbmwjazydwnfkckk-glibc-2.33-50/lib/libc.so.6 (0x0000007f9f267000)
	/nix/store/34k9b4lsmr7mcmykvbmwjazydwnfkckk-glibc-2.33-50/lib/ld-linux-aarch64.so.1 (0x0000007fa292c000)

[Dygear]

AsahiLinux had their alpha release today and I have installed it on my MacBook Pro with M1 Pro chip. After installing rust I cloned Deno and compiled a debug build in ...

    Finished dev [unoptimized + debuginfo] target(s) in 2m 59s
cargo build -vv  12:56.89 user 27.108 system 408% cpu (3:16.66 wasted time).

This was with the graphical environment taking up 50% of the CPU time because it doesn't have GPU acceleration yet.

    Finished release [optimized] target(s) in 10m 30s
cargo build -vv --release  25:12.23 user 26.117 system 244% cpu (10:30.38 wasted time).

Release builds are also very reasonable and should result in a binary that works on Raspberry Pi's but it looks like the version of GLIBC isn't right on the Raspberry Pi OS.

pi@MimoSDR:~ $ ldd --version
ldd (Debian GLIBC 2.31-13+rpt2+rpi1+deb11u2) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
pi@MimoSDR-SCPD1:~ $ ./deno
./deno: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./deno)
./deno: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./deno)
./deno: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./deno)
pi@MimoSDR:~ $ 

[Nexxkinn]

Asahi is probably using a newer glibc version, can you check which glibc version did it use?

[06kellyjac]

the nix build of deno brings its own glibc so if you need deno on PiOS that's an option.

or maybe try use the musl target?

If you don't even have glibc 2.32 you'd have to roll back to rust 1.51 or something and who knows which version of deno you'd have to roll back to. Are you sure you don't have updates available because 2.31 glibc came out 2 years ago

Also just as a note, the nix build is a couple versions behind since we're waiting for rust 1.59 to stablize in our repos and we need it for newer versions of deno

[benz0li]

@kitsonk I am happy to provide a linux/arm64 GitHub Actions Runner if it helps resolving this issue. Are 4 cores and 8 GB RAM (+8GB swap) sufficient?
ℹ️ It would run 24/7 alongside my GitLab Runner in a Debian VM on a Mac mini (M1, 2020).

[06kellyjac]

qemu-user-binfmt is enough to build out rusty_v8 lib, I imagine it'd work just fine for deno in GH actions on x86_64 linux

https://github.com/denoland/rusty_v8/blob/main/.github/workflows/ci.yml#L82-L97

[benz0li]

An arm64 release of deno would be great, because this would be a step forward for an arm64 release of quarto-cli.

I am maintaining registry.gitlab.b-data.ch/ghc/ghc4pandoc (a multi-arch {linux/amd64, linux/arm64/v8} docker image), which is used to build the amd64 and arm64 binary releases of pandoc.
:information_source: Quarto is an open-source scientific and technical publishing system built on pandoc.

[frankhale]

@benz0li You should have a look at this repository. Luke has been shipping Deno arm64 builds for quite some time. You can use those until there is official arm64 builds.

https://github.com/LukeChannings/deno-arm64

[benz0li]

@benz0li You should have a look at this repository.

I know about Luke's arm64 build. I am trying to facilitate an official arm64 release of deno.

[LukeChannings]

qemu-user-binfmt is enough to build out rusty_v8 lib, I imagine it'd work just fine for deno in GH actions on x86_64 linux

https://github.com/denoland/rusty_v8/blob/main/.github/workflows/ci.yml#L82-L97

I actually used QEMU to compile my build originally. You can find the github workflow and dockerfile(s) here if you need a starting point - https://github.com/LukeChannings/deno-arm64/blob/bf6de66d67666a4907cab570e2c4ebc9e4a527dc/.github/workflows/build-deno.yaml.

Note, I stopped using QEMU because since around Deno 1.8.0 builds were failing, I think because of higher RAM requirements. Another factor is time - it takes ~3 hours to compile in QEMU vs ~20 minutes on Apple Silicon. I don't have a dedicated M1 box though, and need to run the GitHub runner on my MacBook ad-hoc, which is also not ideal (I'm on my honeymoon in Trinidad & Tobago, with a poor internet connection, which is why v1.22.3 is taking a while).

@benz0li You should have a look at this repository.

I know about Luke's arm64 build. I am trying to facilitate an official arm64 release of deno.

As far as I know @crowlKats, @kitsonk, @lucacasonato, et al. are still waiting for GitHub to provide official ARM64 runners, which is in turn dependent on Azure officially providing ARM64 instances, which I believe are now available in beta (fact check me tho, I don't use Azure).

The Deno team received an offer of a donated M1 server very early in this ticket (or some other peripheral ticket), and declined. AFAIK nothing has changed about the situation since then.

Just to be clear tho, I want nothing more than an official Linux ARM64 Deno build 😆

[benz0li]

https://github.com/jgm/pandoc/issues/5450 took almost 2 years (Apr 2019 - March 2021) to be resolved. This issue is over 3 years in the making; I am eager to help.

I look forward to some feedback from devs @denoland. In many projects, communication has suffered somewhat in the time of (and after) COVID-19.

[lambdalisue]

It seems GitHub hosted macOS runner for Apple M1 is on an official roadmap now (but on "Future" column) https://github.com/github/roadmap/issues/528

[matteobertozzi]

we are experimenting with a custom AWS lambda runtime the underlying arm64 machine running Amazon Linux 2 is still using Glibc 2.26 so we can't use https://github.com/LukeChannings/deno-arm64 builds

at the moment we do the builds on an ec2 machine and publish the binary here https://github.com/matteobertozzi/deno-aws-lambda-arm

[vinicius73]

It makes me sad.

I've just started new a Telegram Bot, and it should run on a Raspberry Pi. My original intention was to use Deno for it. Unfortunately, I must give up from this idea for now and use Go instead of Deno for this project.

[bartlomieju]

We are working towards resolving this issue.

There are still some PRs that need to be merged to allow it as well as developer bandwidth.

[benz0li]

We are working towards resolving this issue.

There are still some PRs that need to be merged to allow it as well as developer bandwidth.

@bartlomieju Thanks for your feedback from @denoland's side.

[noxifoxi]

@vinicius73

It makes me sad.

I've just started new a Telegram Bot, and it should run on a Raspberry Pi. My original intention was to use Deno for it. Unfortunately, I must give up from this idea for now and use Go instead of Deno for this project.

As long as the official builds are not ready you can use LukeChannings's builds they should run on a raspberry Pi 3 (and newer or any other arm64 hardware (works well on my rockpi4)) without any issues, you can use my fork of the install script to install these binaries properly.

[benz0li]

@bartlomieju It would be great if you could post the status from time to time.

Is there an approximate time frame? Is it weeks or rather months?