incorrect node on non-x86/x86_64 systems

[H-Plus-Time]

emsdk misidentifies the system architecture on ARM systems (I'm fairly certain that the arch checks extend as far as 32/64 bit checks), resulting in the incorrect version of node (and presumably python going by the source) being downloaded - if you replace the contents of node/ with that of the equivalent arm version of node, everything works perfectly.

[juj]

ARM hosts are currently not supported, but Linux/Windows/OS X with 32bit/64bit is assumed. Not sure how to develop a fix since I don't have a suitable ARM host to try on, but PRs with respect to this are welcome.

[cheako]

QEMU has an emulator for ARM, plus u could pick up a rasbpi for under $50.

[bvibber]

Raspberry pi doesn't have enough ram to build, I'm pretty sure. :) I've got a machine I'm going to do some testing on though, might or might not have any luck with it.

[bvibber]

On a Lenovo C630 (Windows 10 on Snapdragon 850) running Ubuntu Bionic in Windows Subsystem for Linux, I was able to build via emsdk install sdk-incoming-64bit. It downloaded an x86-64 node binary, so I had to manually install the distro's node (apt-get install nodejs) and change the NODE setting in ~/.emscripten.

Note the LLVM build took about 2 hours, on a machine with 8 cores and 8 GiB RAM.

Resulting build does appear to work, at least on a "hello world" .c file. :D

Things that need fixing: [ ] distinguish arm and arm64 from x86 and x86-64 somehow, so it doesn't keep trying to install x86/x86-64 stuff [ ] either download an arm/arm64 node, or require it to be installed separately [ ] ideally, provide regular builds for arm64 (this may be tough to set up)

[bvibber]

Ok I see that emsdk distinguishes only between 64-bit and non-64-bit:

def is_os_64bit(): # http://stackoverflow.com/questions/2208828/detect-64bit-os-windows-in-python
  return platform.machine().endswith('64')

So it'll see the "aarch64" and report back 64-bit, but doesn't distinguish arches in any other way. This can probably be modified around to return a normalized arch name; to keep back-compat could keep calling x86 32bit and x64 64bit, and add arm32 and arm64 or something alongside.

Or, 'Linux' as an OS could be split into 'linux' for x86/x86-64 and 'linux-arm' for arm/aarch64, with each having its 32-bit and 64-bit variants. I think this would be easier/less invasive to the codebase.

@juj do you have a preference for which of those I should try making a test patch? Thanks!

[bvibber]

My initial patch adds a LINUX_ARM OS type so it won't download any Linux x86/x64 binaries. Could be extended further to check for linux_arm_url download URLs if there's interest in publishing any.

Note that the sdk-incoming-64bit etc metapackages don't work because they depend on the node package, which has binaries only, so you instead have to manually install the subcomponents.

If a binary node package could be added, that'd get the sdk metapackages working even if none of the build generation creates binaries for llvm/clang/binaryen which can be done locally (if you have enough RAM!)

[bvibber]

Per juj's note on the commit I'll try switching it to have a proper ARCH variable this weekend. Adding more arches gets complex otherwise, lots of if/ors :)

[Ghabry]

I attempted to use emscripten on arm64 M1 macOS.

Just got a failure in node: "[Errno 86] Bad CPU type in executable".

So likely still wrong node version picked?

[sbc100]

@Ghabry, I believe M1 macOS should be supported, at least since #753. That PR has this as part of the comment:

* Fix support for Apple M1. Node.js will still run via Rosetta 2 emulation since they do not yet have M1 support, but Python, LLVM, Emscripten and Binaryen will be native.

So it seems that it should work via Rosetta. Is it possible to disable Rosetta somehow? Have you disabled it? Its possible we could revisit and try to get an arm64 version of node.. but it should be required to get things working for you.

[haberbyte]

@sbc100 Just leaving this here as a note: According to https://github.com/nvm-sh/nvm#macos-troubleshooting, node v16 is the first version with full M1 support, so I guess emsdk would need to upgrade from 14 to 16 to not depend on rosetta 2 emulation.