Re-add Windows arm64 (un)official builds

[dennisameling]

While trying to add Windows arm64 support to GitHub Desktop, I came across some issues with the NodeJS Windows arm64 binaries. The Electron part of the app works fine, as they've been supporting Windows arm64 for a while (e.g. http://electronjs.org/headers/v9.3.1/win-arm64/node.lib).

The last NodeJS release that had unofficial arm64 builds was 12.15.0: https://unofficial-builds.nodejs.org/download/release/v12.15.0/win-arm64/, all versions after that don't have a win-arm64 folder anymore.

gyp http 404 https://nodejs.org/download/release/v12.18.4/win-arm64/node.lib

Even in the latest 14.13.0: no trace of Windows arm64. (https://unofficial-builds.nodejs.org/download/release/v14.13.0/ and https://nodejs.org/download/release/v14.13.0/). Cross-compilation support for Windows arm64 was restored in nodejs/node#32867, but since then no new builds have been released.

error D:\repos\desktop\node_modules\keytar: Command failed.
Exit code: 1
Command: prebuild-install || node-gyp rebuild
Arguments:
Directory: D:\repos\desktop\node_modules\keytar
Output:
prebuild-install WARN install No prebuilt binaries found (target=12.18.4 runtime=node arch=arm64 libc= platform=win32)

D:\repos\desktop\node_modules\keytar>if not defined npm_config_node_gyp (node "C:\Program Files\nodejs\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node ""C:\Users\Dennis\AppData\Roaming\npm\node_modules\node-gyp\bin\node-gyp.js"" rebuild )
gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | win32 | x64
gyp info find Python using Python version 3.7.3 found at "C:\Program Files\Python37\python.exe"
gyp http GET https://nodejs.org/download/release/v12.18.4/node-v12.18.4-headers.tar.gz
gyp http 200 https://nodejs.org/download/release/v12.18.4/node-v12.18.4-headers.tar.gz
gyp http GET https://nodejs.org/download/release/v12.18.4/SHASUMS256.txt
gyp http GET https://nodejs.org/download/release/v12.18.4/win-x86/node.lib
gyp http GET https://nodejs.org/download/release/v12.18.4/win-x64/node.lib
gyp http GET https://nodejs.org/download/release/v12.18.4/win-arm64/node.lib
gyp http 200 https://nodejs.org/download/release/v12.18.4/SHASUMS256.txt
gyp http 404 https://nodejs.org/download/release/v12.18.4/win-arm64/node.lib
gyp http 200 https://nodejs.org/download/release/v12.18.4/win-x86/node.lib
gyp http 200 https://nodejs.org/download/release/v12.18.4/win-x64/node.lib
gyp info find VS using VS2019 (16.7.30503.244) found at:
gyp info find VS "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community"
gyp info find VS run with --verbose for detailed information
gyp info spawn C:\Program Files\Python37\python.exe
gyp info spawn args [
gyp info spawn args   'C:\\Users\\Dennis\\AppData\\Roaming\\npm\\node_modules\\node-gyp\\gyp\\gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'msvs',
gyp info spawn args   '-I',
gyp info spawn args   'D:\\repos\\desktop\\node_modules\\keytar\\build\\config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   'C:\\Users\\Dennis\\AppData\\Roaming\\npm\\node_modules\\node-gyp\\addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   'C:\\Users\\Dennis\\AppData\\Local\\node-gyp\\Cache\\12.18.4\\include\\node\\common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=C:\\Users\\Dennis\\AppData\\Local\\node-gyp\\Cache\\12.18.4',
gyp info spawn args   '-Dnode_gyp_dir=C:\\Users\\Dennis\\AppData\\Roaming\\npm\\node_modules\\node-gyp',
gyp info spawn args   '-Dnode_lib_file=C:\\\\Users\\\\Dennis\\\\AppData\\\\Local\\\\node-gyp\\\\Cache\\\\12.18.4\\\\<(target_arch)\\\\node.lib',
gyp info spawn args   '-Dmodule_root_dir=D:\\repos\\desktop\\node_modules\\keytar',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'D:\\repos\\desktop\\node_modules\\keytar\\build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
gyp info spawn C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe
gyp info spawn args [
gyp info spawn args   'build/binding.sln',
gyp info spawn args   '/clp:Verbosity=minimal',
gyp info spawn args   '/nologo',
gyp info spawn args   '/p:Configuration=Release;Platform=ARM64'
gyp info spawn args ]
Building the projects in this solution one at a time. To enable parallel build, please add the "-m" switch.
  async.cc
  main.cc
  keytar_win.cc
  win_delay_load_hook.cc
LINK : fatal error LNK1181: cannot open input file 'C:\\Users\\Dennis\\AppData\\Local\\node-gyp\\Cache\\12.18.4\\arm64\\node.lib' [D:\repos\desktop\node_modules\keytar\build\keytar.vcxproj]
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Users\Dennis\AppData\Roaming\npm\node_modules\node-gyp\lib\build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (events.js:315:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
gyp ERR! System Windows_NT 10.0.19041
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\Dennis\\AppData\\Roaming\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd D:\repos\desktop\node_modules\keytar

Are there any blockers to start releasing Windows arm64 builds for NodeJS? AFAIK we should be good to go:

• jenkins: add ARM64 Windows #2408 is merged (add arm64 to Jenkins)
• build: move compiling for Windows ARM64 to Tier 2 node#34721 is merged (move Windows arm64 to Tier 2 support)

According to nodejs/node#25998 (comment):

The next step is to update the job used for unofficial releases and start publishing them again. Note that for now there will be no MSI because WiX 3.14 is not yet released, but as soon as it is we should get the MSI as well.

Please let me know if I can be of any help. Very eager to help open source projects get arm64 support to the Windows platform soon 😊

[AshCripps]

Best person to ask would be @joaocgreis as I believe the machines used to build it are hosted on his desk.

[joaocgreis]

v14.13.0 published: https://unofficial-builds.nodejs.org/download/release/v14.13.0/

It was not possible to run the tests for this release because the machines we have are currently offline, I'll check on them and run the tests when possible. @dennisameling if you can try the release and confirm it works, that would be appreciated.

Note the release process for this is manual - the unofficial releases server uses docker for the Unix platforms but for Windows it must run in the CI test machines. I will try to publish releases frequently but can't commit to publish every version.

To move this further forward, we need ARM64 machines to become available in Azure.

[dennisameling]

Thanks @joaocgreis! Can confirm the release works. Have been trying some things and all looks good so far.

I was also able to build an MSI installer from the v14.13.0 tag, here's the link in case someone's interested: https://github.com/dennisameling/node/releases/tag/v14.13.0-arm64 (I'm using this on my Surface Pro X now 🎉)

Have you considered running a self-hosted Azure Pipelines agent, like the Electron team is doing? You can run the 32-bit Azure Pipelines agent on an ARM64 device like the Surface Pro X.

Hopefully that's a feasible workaround for the time being; I'll try to get in touch with Azure support to ask when ARM64 machines will become available. Guess it's only a matter of time, hopefully sooner than later 🚀

UPDATE: Got a response from Azure Support on Twitter. They don't have info regarding potential availability of ARM64 runners at the moment: https://twitter.com/AzureSupport/status/1313067495444688896. Have created a support case with the Azure DevOps team just to cross-check with them as well.

UPDATE 2: Got a response from Azure Support in my ticket:

In regards to the reported scenario I would like to let you know that I have checked the Azure DevOps Roadmap, the Azure DevOps Features Timeline and also discussed the ticket internally with the escalation engineers and unfortunately the desired feature / functionality is not available.

What we can recommend in this situation is to go to the developer community and request this as a new feature for DevOps: https://developercommunity.visualstudio.com/content/idea/post.html?space=21 .
We use this tool to learn what our customers want and where we should focus on improving. People can make their own suggestions and vote on others’ suggestions they’d like to see. Our product group then tries to implement the suggestions that have a lot of community support.

I created a feature request back in May, please upvote if you'd like to see hosted Windows ARM64 agents in Azure: https://developercommunity.visualstudio.com/idea/1015752/please-add-a-windows-arm64-hosted-agent.html

For the time being, a self-hosted Azure Pipelines Agent on e.g. a Surface Pro X could be an option maybe, as mentioned above.

[joaocgreis]

Published v14.13.1.

CI: https://ci.nodejs.org/view/All/job/node-test-commit-windows-fanned/38639/

test-dgram-udp6-link-local-address seems to always fail, but it may be because of the configuration of the machine.

@dennisameling we are using essentially the same thing as a self-hosted agent, but connected to our Jenkins system. This is not a reliable setup though, the machine was offline and I could only bring it back now. That's one of the reasons why we need the cloud hosted machines, the other is simply we need more machines.

[joaocgreis]

Published v15.5.1.

[EwoutH]

Could the win-arm64 directory, including node.lib, be retroactively be added to the latest LTS versions? So at least v12.20.1 and v14.15.4.

[joaocgreis]

Published v14.15.4 and v15.8.0.

@EwoutH didn't publish v12 because it doesn't have ARM64 support.

[joaocgreis]

Published v14.17.0 and v16.2.0.

From the CI runs (14, 16) it looks like there's a new failure running node-gyp. I can't investigate now, it may be only an issue with CI or may be relevant.

[joaocgreis]

Published v14.17.5 and v16.6.2.

[jeremyd2019]

Hey - Github actions runner updated to node.js 12.22.7 and 16.13.0. I've been running and rebasing Windows ARM64 support from actions/runner#785, but this failed when trying to build the latest release due to there not being any Windows ARM64 builds of those versions of node.js. Could someone spare some cycles to get those versions? The GHA runner insists on trying to update itself when it thinks its out of date, and exits when it sees there's no official Windows ARM64 build it can update to, so it becomes pretty useless when out of date.

[dennisameling]

@jeremyd2019 have you tried using the x64 GH Actions runner for now on Windows 11 ARM64? I'm using that for a self-hosted runner in combination with Node 16.13.0 ARM64 (added to PATH): https://github.com/dennisameling/node/releases/tag/v16.13.0-arm64. Figured this is the easiest way to have a stable runner until official Node ARM64 builds are available 😊

[jeremyd2019]

No, I haven't. But I guess I shot myself in the foot there, because of actions/runner#1372, and I now use ${{ runner.arch }} to tell if I'm on an ARM64 runner

[jeremyd2019]

Thanks for the pointer to an arm64 build of 16.13.0! I at least managed to get a build to complete using that and 12.15.0 (which seems to be the last 12.x build with a win-arm64 unofficial build). jeremyd2019/runner@9c0640c Will have to see if it blows up on me or not.

[jeremyd2019]

It looks like upstream runner reverted to 12.13.1, so I only have to use 16.13.0 from @dennisameling's fork, at least for the moment.

[joaocgreis]

Published v16.13.2 and v17.4.0

[joaocgreis]

Published v16.14.0 and v17.5.0

[jeremyd2019]

github actions/runner just updated to 12.22.7 again (calling it "the latest" node12) 😦 Any chance of getting a newer node12 win-arm64 build?

[jeremyd2019]

I made an attempt to build 12.22.7 on win-arm64. It failed, apparently lacking an implementation of PlatformEmbeddedFileWriterWin::DeclareRvaToSymbol for the V8_ASSEMBLER_IS_MARMASM case. Jumping ahead to the 14.x branch, that code was refactored and there is an arm64 implementation in that function (but not in the tip of the 12.x branch). So I guess I'm sticking to 12.15.0 for now.

[joaocgreis]

Published v18.11.0 and v16.18.0:

• https://unofficial-builds.nodejs.org/download/release/v18.11.0/
• https://unofficial-builds.nodejs.org/download/release/v16.18.0/

These versions were not tested in CI. I launched the Jenkins jobs but they are not starting the ARM executors, this will have to be investigated.

@jeremyd2019 IIRC, support broke at some point during the life cycle of v12 because of a difficult bug, and it was only fixed much later on v14. It may be possible to fix v12, but would not be easy.

[jeremyd2019]

Thanks. Since my last update, github has deprecated node12 in actions/runner, and has finally published a "pre-release" official win-arm64 runner (with no node12 runtime, which seems to match what they did for osx-arm64). So it looks like I no longer need to care about this directly, somebody at github is worrying about it for me!

[Macmee]

@joaocgreis wow this work amazing for me on my SP9 SQ3! Any idea why nodejs.org doesnt publish these?

[joaocgreis]

Published the latest versions:

• https://unofficial-builds.nodejs.org/download/release/v19.3.0/
• https://unofficial-builds.nodejs.org/download/release/v18.12.1/
• https://unofficial-builds.nodejs.org/download/release/v16.19.0/

@Macmee we're working towards having ARM64 Windows as an officially supported platform, and then every Node.js version will have ARM64 Windows binaries published along with the rest. For now, we don't yet have proper CI support, so the binaries I published weren't properly tested and are much more likely to have issues.

[joaocgreis]

ARM64 Windows is officially supported now!