Apple Silicon Support

[AshCripps]

This issue to provide visibility about our plans and progress to supporting Apple Silicon natively.

Refs: nodejs/TSC#886
Refs: nodejs/build#2474

Current plan is to have native support for 16.x via a universal binary supporting both Arm and Intel architecture.

NOTE: Support is very unlikely to be back ported to 14.x or before due to requiring a SemVer Major V8 update

How to run Node.js on Apple Silicon currently

You can either build from source on 15.x - This is not officially supported so don’t expect a smooth experience
You can also run x64 Node.js binaries via the translation layer.

Current Known Bugs

• Check failed: allocator->SetPermissions - macOS 11.2: Fatal error Check failed: allocator->SetPermissions #37061 - deps: V8: workaround for darwin arm64 code page decommit failures #37276 has landed.
• make check failure - make check failure for macOS arch64 #36656 - deps: cherry-pick 8957d4677aa794c230577f234071af0 from V8 upstream #37471 has landed.

To Do List

• Add 11.0 to versionselector to ensure we build only on master
• Enable the macos-arm job in normal test regressions
• Get the DTKs back into CI for testing
• Test compiling and running node natively on the mac arm hardware
• Test if a current release runs on the new hardware through the translation layer
• Figure out a source of hardware to add to our CI for when our DTKs go back to apple
• Note down size difference in binaries between: intel, arm and fat.
• Change makefile to build universal binaries
• Edit release job to build the new binary

This issue is locked as we will use it to provide updates on progress. If you need help please open an issue on https://github.com/nodejs/help/issues

[AshCripps]

node-test-commit-osx-arm is now enabled in the regular CI runs (example run: https://ci.nodejs.org/job/node-test-commit/44655/). I will be keeping an eye on it to check thats its working correctly

[targos]

Change makefile to build universal binaries

Has someone looked into this? It seems that it can be done independently of the other steps, and since v16.0.0 is quite close, I think it would be nice if we could start building the fat binary for nightlies.

[AshCripps]

I haven't had the time yet, but its open to anyone interested in helping out.

[AshCripps]

Also today I got 3 M1 minis from macstadium so Im setting them up today

[AshCripps]

I tried cross compiling on a M1 to intel arch using some steps in nodejs/build#2474 (comment) but hit the following error:

In file included from ../deps/v8/src/base/bits.cc:5:
In file included from ../deps/v8/src/base/bits.h:12:
In file included from ../deps/v8/src/base/macros.h:12:
In file included from ../deps/v8/src/base/logging.h:13:
../deps/v8/src/base/build_config.h:153:2: error: Target architecture x64 is only supported on x64 host
#error Target architecture x64 is only supported on x64 host

@rvagg I am a total novice at this so is there anything obvious that sticks out about this error?

[rvagg]

Yeah, whacky, it's V8 blocking this:

node/deps/v8/src/base/build_config.h

Lines 151 to 154 in 52f9aaf

	#if (V8_TARGET_ARCH_X64 && V8_TARGET_ARCH_64_BIT && \
	!(V8_HOST_ARCH_X64 && V8_HOST_ARCH_64_BIT))
	#error Target architecture x64 is only supported on x64 host
	#endif

So V8 has opinions about which direction you can cross-compile. That whole surrounding section has strong assertions about which host->target combinations you can cross-compile V8 in. I don't really understand why they need to have such opinions but I guess they have some pretty deep architecture affinity things going on where they have constraints for what to practically support. @targos comes to mind as someone who might have some insight into the why here.

But this does answer the question we had at the meeting this week - can we support both architectures on an arm64 release host - NO, for now at least. x64 reigns supreme. So we need to invest in getting the x64->arm64 cross path working cleanly so we can do fat binaries for the .pkg.

[targos]

I just learned today about this build config header, no idea why V8 has this limitation.

[targos]

What was the reason for creating an universal binary?
If I understand correctly, it will be about twice as large as the current one. Tools like nvm currently build from source by default on M1 and I think homebrew has a separate arm64 build so it looks like the community expects it to be like that.

[rvagg]

@targos the universal is for the .pkg download, there will still be architecture-specific tarballs that nvm and friends can use.

[AshCripps]

Thats a shame its blocked in V8 the arm machines are so much faster. Ill try and get x86 to arm working then and also check the tar building step works as it should on arm

[AshCripps]

Thanks to a suggestion @andreialecu from I compiled node under rosetta (didn't even consider compiling under rosetta) and got an x64 binary out on m1

administrator@26684 node % arch
arm64
administrator@26684 node % file out/Release/node
out/Release/node: Mach-O 64-bit executable x86_64

Was a super slow process though - took well over an hour. Also is rosetta a trustworthy path? is it likely to go away before the intel machines do making this process eventually redundant?

[AshCripps]

That was easier than I expected:

administrator@26684 test % file node-uni
node-uni: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
node-uni (for architecture x86_64):	Mach-O 64-bit executable x86_64
node-uni (for architecture arm64):	Mach-O 64-bit executable arm64
administrator@26684 test % ./node-uni -p process.arch
arm64
administrator@26684 test % arch -x86_64 ./node-uni -p process.arch
x64

[aduh95]

Should the OP be updated now that #38051 has landed?

[AshCripps]

Closing as Apple silicon is now fully supported with the release of 16.x. Whilst support is in 14.x we are going to wait for a bit and see if 16.x throws up any bugs. For 14.x it will likely be only the tar will be released for M1 and not the updated pkg.

[rvagg]

big thankyou to @AshCripps for powering through this and delivering binaries!