Add support for 32-bit ARM processors

[jkdmyrs]

When attempting to install deno on my Raspberry Pi, I get the following:

$ curl -fsSL https://deno.land/x/install/install.sh | sh -s v0.4.0 Unsuported architecture armv7l. Only x64 binaries are available.

Is support for 32-bit ARM processors something we can eventually expect?

[kitsonk]

arm64 was introduced in #1846, which was really done by someone wanting to contribute it, an arm32 build likely would need to be done the same way.

[potham]

@jkdmyrs me also faced the same issue.

[afinch7]

I would like to get builds for arm32+arm64 into the wild, but we had quite a few issues with testing last time.

[FossPrime]

Without this it means Deno won't run on Raspberry Pi Zero, Zero W, 1, or 2...

Source: https://en.wikipedia.org/w/index.php?title=Raspberry_Pi&section=12#Specifications

Update: Ubuntu now has an official ARM64 version with Unity. Raspbian also has a beta version out of a long overdue x64 faster version.

[ry]

We certainly would love to produce arm builds. In order for this to happen the test suite needs to run in CI - presumably in travis under qemu.

We had some tentative support for arm64 a while ago, but it was removed [for various reasons]. Have a look for a good starting point.

[stephenwil]

@afinch7 Where did you get to with an arm build?

[ry]

rusty_v8 (deno's major dependency) now has aarch64 builds in CI: https://github.com/denoland/rusty_v8/commit/ffdf69bd0074bb0b03aceeb76b521ab869d13a2f So we're a bit closer to an arm build here but I think it will still take quite a bit of work to actually get deno's CI working.

[Qws]

Deno for ARM 32bit (usually Raspberries) are really appreciated.

Maybe it can even be bundled standardly with Debian/Raspbian instead of Node.js. Because Node.js doesn't has official 32bit ARM support. Debian ports it themselves, which is sadly still 2 version behind the official 64bit counterpart and also can cause problems for NPM (well according to their warnings).

[FalseDev]

Deno for ARM 32bit (usually Raspberries) are really appreciated.

Maybe it can even be bundled standardly with Debian/Raspbian instead of Node.js. Because Node.js doesn't has official 32bit ARM support. Debian ports it themselves, which is sadly still 2 version behind the official 64bit counterpart and also can cause problems for NPM (well according to their warnings).

You can install nvm and have any version of node working , I'm using it and had absolutely no problem

[vintprox]

Sitting from Termux, architecture "armv71". What are safe build instructions for 32-bit ARM to try out right now?

[FossPrime]

@vintprox There are none... 32bit ARM is on it's way out quickly... Pi 3 and 4 both support ARM64, Ubuntu Unity was ported to ARM64, Raspbian is fairly stable... Ubuntu Core and Server are rock solid on ARM64 for Raspberry Pi. Treat those devices as vintage/arduino style hardware... The last holdout for me is the RPi Zero... which should get an update soon

[vintprox]

There are none... Arm 32 is on it's way out quickly

If I interpreted it correctly, that's sad. Wanted to try out Deno on Android badly, but it turns out I'm sticking with JS for real fast prototyping until I get PC. 🤷‍♂️

[robertjbass]

I got a Surface Pro X and for some reason the first thing I wanted to do with it was learn Deno. I'm so disappointed. choco install deno 💔

[FossPrime]

@vintprox @716green ... The Samsung Galaxy S4 was the first to make the jump to a 64bit ARM processor. That came out, spring 2013. Google Play effectively ended support for ARM v7a processors in 2019. You may need to flash a post Lolipop version of Android to make it run in 64 bit though... released in 2014.

The Surface Pro X is an amazing computer with one of the fastest ARM64 capable processors out there... it can run deno without issue. User agent sniffers might be giving you bad packages... you want the x86 or ARM64 versions of apps NOT the "x64" or "x86_64" or "amd64" versions, which all refer to the same non-ARM, Intel x686 derived, instruction set which is incompatible with the emulator Microsoft uses. Intel x64 emulation for ARM64 will be supported "in the first half of 2021" after Microsoft finishes adding support to their emulation engine.

[robertjbass]

@vintprox @716green ... The Samsung Galaxy S4 was the first to make the jump to a 64bit ARM processor. That came out, spring 2013. Google Play effectively ended support for ARM v7a processors in 2019. You may need to flash a post Lolipop version of Android to make it run in 64 bit though... released in 2014.

The Surface Pro X is an amazing computer with one of the fastest ARM64 capable processors out there... it can run deno without issue. User agent sniffers might be giving you bad packages... you want the x86 or ARM64 versions of apps NOT the "x64" or "x86_64" or "amd64" versions, which all refer to the same non-ARM, Intel x686 derived, instruction set which is incompatible with the emulator Microsoft uses. Intel x64 emulation for ARM64 will be supported "in the first half of 2021" after Microsoft finishes adding support to their emulation engine.

Where can I get a package that's compatible with the SQ1 ARM64 processor in my Surface Pro X? The recommended install is through Chocolatey from what I've read.

[user21944]

I'd like to start using Deno instead of Node.js for servers on my Raspberry Pi 2B, and the fact that arm32 is still missing continues to be a roadblock. I can't upgrade at the moment, and the Raspberry Pi 2 is still in production so I see no reason for this to not be supported.

[Dygear]

Now that we have Experimental support for Mac Arm64 and arm64 on linux works fairly well. The last thing is arm32 within the triple target for me. The only reason I actually want this is because of the Raspberry Pi Zero (WH) that still has the older 32bit core. I'm going to start poking around Raspberry Pi to see if what they did to get v8 on the 32 bit builds of Raspberry Pi OS. @spl237 (Simon Long) is really the person that I would love to talk to, he's the Senior Principal Software Engineer over at the Raspberry Pi Foundation and somehow he builds V8 on the Raspberry Pi OS for 32 bit CPUs. So there is clearly something to learn there that can be used here.

[spl237]

Nothing to do with me, I'm afraid - our 32-bit builds are a third-party project called Raspbian, and we don't make them ourselves. See https://www.raspbian.org for details - asking a question on the forums there is probably a good start.

[Dygear]

@spl237 Thanks for pointing me in the correct direction!

[SebFox2011]

Hello tryed to install on rasp WO with exec format error

pi@raspberrypiW0:~ $ curl -fsSL https://deno.land/x/install/install.sh | sh ######################################################################## 100.0%# ######################################################################## 100.0%# ######################################################################## 100.0% Archive: /home/pi/.deno/bin/deno.zip inflating: /home/pi/.deno/bin/deno Deno was installed successfully to /home/pi/.deno/bin/deno Manually add the directory to your $HOME/.bash_profile (or similar) export DENO_INSTALL="/home/pi/.deno" export PATH="$DENO_INSTALL/bin:$PATH" Run '/home/pi/.deno/bin/deno --help' to get started pi@raspberrypiW0:~ $ deno -h -bash: deno: command not found pi@raspberrypiW0:~ $ /home/pi/.deno/bin/deno --help -bash: /home/pi/.deno/bin/deno: cannot execute binary file: Exec format error pi@raspberrypiW0:~ $

[kitsonk]

There is a reason the issue is open, because there isn't support yet.

[jimmont]

What is the window of time in which this may be supported using the standard install method? Or instructions available for self-install? I'd like to begin using Deno for projects slated over the coming months deploying to RPI3 32bit Raspberry PI OS-current (as well as 64bit and RPI4 32 and 64bit Raspberry Pi OS) and haven't been successful using cargo install deno --locked myself on the RPI3 (RPI4 works fine with 64bit though, takes about 1 hour). Thanks.

[Dygear]

I don't think they will ever support arm32. While there are plenty of edge devices out there that are using arm32, there are far more that are going to be arm64 with a lot more power. I have a Raspberry Pi Zero that I would love to run Deno, but I don't think that will ever be in the cards given the how hard it is to get a version of V8 running on that platform.

[d3lity]

I did get it to work on Raspberry 4 (Raspberry Pi OS Lite 32bit) but it did took some work like:

// kernel to 64bit /boot/config: arm_64bit=1

// resize swap sudo dphys-swapfile swapoff sudo nano /etc/dphys-swapfile // Changes (you can also get by with only 2048): CONF_SWAPSIZE=4096 CONF_MAXSWAP=4096

sudo dphys-swapfile setup sudo dphys-swapfile swapon sudo reboot

sudo apt-get install -y raspbian-nspawn-64

ds64-shell // inside new shell:

sudo apt-get install curl unzip

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh // change if not automatically detected: default host triple: aarch64-unknown-linux-gnu

sudo apt-get install gcc g++

sudo mount -o remount,size=9G /tmp/

cargo install deno

[synaptiko]

Just an idea, could cross-compilation be handled by Zig? Similar to what's described here: https://dev.to/kristoff/zig-makes-go-cross-compilation-just-work-29ho

Zig can also be used by cc-rs, a Rust crate used for shelling out to a C/C++ compiler, for example.

[jerrygreen]

I tried building from source using this guide: https://deno.land/manual@v1.12.1/contributing/building_from_source

I use Raspberry Pi 4, 8gb, but after several minutes of building it's stuck into:

error: failed to add native library /home/pi/.deno/bin/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`

...

error: build failed

P.S. I'm actually wondered why this error occurs. The manual says that to build deno I have to pass special env variable: V8_FROM_SOURCE=1 cargo build -vv, but even building with simple cargo build -vv, - emits an error about compiling rusty_v8... (and V8_FROM_SOURCE=1 doesn't make a difference)

[almereyda]

While this issue covers armhf builds of Deno, to mirror the architecture naming from Ubuntu ¹, the previous error might not be related to that platform. A Raspberry Pi 4 is known to run arm64, next to other platforms(32-bit ARM can be emulated, Java bytecode runs natively, as in Android). While it is certainly possible to install and run a 32-bit system on the devices, it would rather not be suggested. Which was the case here in the example before?

Eventually mine and the previous comment can be hidden, as long as they don't add anything new to the original issue.

Footnotes

¹ Hard Float images are the naming that Canonical use on https://cdimage.ubuntu.com/releases/21.10/release/

[jakobkummerow]

@Dygear

given how hard it is to get a version of V8 running on that platform

For the record: upstream V8 is straightforward to compile on arm32 (I've successfully done it myself, on a Raspi) or cross-compile for arm32 (that's e.g. how Chrome for Android gets built). This issue is all about adding such support to Deno's / rusty_v8's build and bindings system. From a related complaint I saw elsewhere recently, my understanding is that supporting 32-bit builds at all (regardless of x86 or arm) might be quite a bit of work.

[Dygear]

From a related complaint I saw elsewhere recently, my understanding is that supporting 32-bit builds at all (regardless of x86 or arm) might be quite a bit of work.

If you could provide a guide for building it for 64bit on Raspberry Pi OS (64bit) that would be extremely helpful given that the Raspberry Pi foundation has now officially released the 64bit version of their OS. Ideally including all packages required to be installed via apt.

[jakobkummerow]

These are my notes from last year, using Ubuntu 2020.10: https://docs.google.com/document/d/1u-HAFfjWIH3WY3xajuGxGii-lWi1rpf16hVmB-mRdTA/edit?usp=sharing, including all packages I installed. I'd expect Raspberry Pi OS to be very similar, but I don't have time to verify that currently.

For cross-compiling from Linux x64, I think that installing the right sysroot and putting target_cpu = "arm64" into your args.gn should be all you need.

See also: https://v8.dev/docs/build-gn (general instructions) and https://v8.dev/docs/compile-arm64.

[lino-levan]

For those who are curious, the reason cross compile doesn't work is because snapshotting doesn't work cross platform.

[somombo]

For those who are curious, the reason cross compile doesn't work is because snapshotting doesn't work cross platform.

@lino-levan so how does node.js do it then? and what do you suggest as an alternative solution?

[somombo]

I wonder if cross compiling using zig would fix this

[ubuntupunk]

bump, exec format error on raspberry 32bit, snap available, but only 64bit it seems.

[seriousme]

Would be nice if the install script would abort instead of just installing X86 binaries :-(

ie. install.sh currently contains:

if [ "$OS" = "Windows_NT" ]; then
        target="x86_64-pc-windows-msvc"
else
        case $(uname -sm) in
        "Darwin x86_64") target="x86_64-apple-darwin" ;;
        "Darwin arm64") target="aarch64-apple-darwin" ;;
        "Linux aarch64") target="aarch64-unknown-linux-gnu" ;;
        *) target="x86_64-unknown-linux-gnu" ;;
        esac
fi

uname -sm on my OrangePi Zero returns Linux armv7l

[lucacasonato]

Deno does not support any other 32 bit platforms (like x86), so we are not going to work on this. The era of 32 bit processors is over.

[KaKi87]

Deno does not support any other 32 bit platforms (like x86)

We're talking about ARM, not x86.

The era of 32 bit processors is over

Raspberry Pis beg to differ.

[Dygear]

Deno does not support any other 32 bit platforms (like x86), so we are not going to work on this. The era of 32 bit processors is over.

Yeah, that's fair. In the 5 years that this has gone on, the need for this has been less and less. Especially with the Zero W 2, and the Pi 5 both having easy to use 64-bit implementations of their OS.

[seriousme]

Deno does not support any other 32 bit platforms (like x86), so we are not going to work on this. The era of 32 bit processors is over.

Thats a legitimate position to hold, I'm not asking for 32 bit binaries. In my view however its suboptimal to just assume a platform and install random binaries.

From a defensive coding perspective I would say that the default *) outcome of the uname -sm should be "platform not supported" and only known values should lead to binaries being installed.

My 2cts.