It looks as though the code-oss binary in the ARM64/aarch64 packages is actually a 32 bit executable (code-oss: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=14b6a9ab1263520c73d76aafa59a326d291a44f8, stripped)
I'm making slow progress through the build system to work out what needs to be done - others are likely to be faster than I!
This is true - Electron currently doesn't support ARM64, so I wanted to get this to the point that it will be trivial to change at this side (which it now is) when they have it ready over there.
I wanted to have arm64 packages out in the meantime that people could use now - Electron will run as a 32-bit executable, but everything else (like the native extensions) are compiled to ARM64 (things like Oniguruma and node-gyp) to reap whatever benefits can be had from ARMv8 on those devices.
It also means that if/when Electron starts shipping ARM64 binaries I can switch over without breaking anything (users would likely not even know unless they had your shell savvy-ness!)
Edit: By the way, if you're looking for a starting point check out Chromium Embedded Framework (CEF), that's where we'd need to start with building out ARM64 support last I looked (then Electron, then this project).
Cool, thanks. I was trying to run the tool on one of Packet.net's ThunderX servers, which have no 32-bit support in the CPU itself. I'm grateful for your kudos, but it might be misplaced - I wouldn't have engaged my shell-foo if it had run :)
Will take a look at CEF, though my dev skills have atrophied in recent years.
Honestly, it looks like CEF is in good shape to build for ARM64, I just don't know anyone that does currently (it's a looooong build - so it rules out CI I think)
I'm making slow progress through the build system to work out what needs to be done - others are likely to be faster than I!