Repository navigation
Apple Silicon Support #37309
Copy link
Copy link
Closed
Labels
buildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.macosIssues and PRs related to the macOS platform.Issues and PRs related to the macOS platform.
Description
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->SetPermissionsmacOS 11.2: Fatal error- deps: V8: workaround for darwin arm64 code page decommit failures #37276 has landed.Check failed: allocator->SetPermissions#37061 -
-make check failuremake 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
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
buildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.macosIssues and PRs related to the macOS platform.Issues and PRs related to the macOS platform.
Activity
AshCripps commentedon Feb 25, 2021
node-test-commit-osx-armis 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 correctlytargos commentedon Mar 10, 2021
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 commentedon Mar 10, 2021
I haven't had the time yet, but its open to anyone interested in helping out.
AshCripps commentedon Mar 10, 2021
Also today I got 3 M1 minis from macstadium so Im setting them up today
AshCripps commentedon Mar 18, 2021
I tried cross compiling on a M1 to intel arch using some steps in nodejs/build#2474 (comment) but hit the following error:
@rvagg I am a total novice at this so is there anything obvious that sticks out about this error?
rvagg commentedon Mar 19, 2021
Yeah, whacky, it's V8 blocking this:
node/deps/v8/src/base/build_config.h
Lines 151 to 154 in 52f9aaf
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 commentedon Mar 19, 2021
I just learned today about this build config header, no idea why V8 has this limitation.
targos commentedon Mar 19, 2021
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
nvmcurrently 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 commentedon Mar 19, 2021
@targos the universal is for the .pkg download, there will still be architecture-specific tarballs that
nvmand friends can use.AshCripps commentedon Mar 19, 2021
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 commentedon Mar 19, 2021
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
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 commentedon Mar 22, 2021
That was easier than I expected:
aduh95 commentedon Apr 13, 2021
Should the OP be updated now that #38051 has landed?
AshCripps commentedon Apr 22, 2021
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 commentedon Apr 22, 2021
big thankyou to @AshCripps for powering through this and delivering binaries!