Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

src,win: add support for fetching arm64 node.lib #1875

Closed

Conversation

richard-townsend-arm
Copy link
Contributor

Checklist
  • npm install && npm test passes
  • tests are included
  • commit message follows commit guidelines
Description of change

Windows on Arm support is available in some versions of Node.js v12 and Electron v6. This update allows node-gyp to fetch the appropriate node.lib to build native modules. If an arm64 binary is not available for the target node version, it's logged but ignored.

arm64 is not expected to work in very old node.lib distribution formats, the test URLs in these cases are added to be consistent with x64.

@joaocgreis
Copy link
Member

@richard-townsend-arm thanks for opening this PR! This has been on my backlog for a while, because some more changes are needed. Now it's almost done:

  • The Unofficial Builds server needs to have node.lib for ARM64. I've made the changes and I'm using https://unofficial-builds.nodejs.org/download/release/v12.8.0/ to test.
  • I'd rather avoid having x86 and x64 binaries in that server to avoid confusion, so node-gyp needs to ignore failures downloading those as well. I've pushed a commit here to address this, but I can take it back if you prefer that I don't change this PR. A better solution would be to download only the file needed for the target architecture, but that's a much less simple change. I believe this is good for now.
  • The Unofficial Builds server needs to have a copy of the headers and a RELEASE_URLBASE pointing to it: change RELEASE_URLBASE to the Unofficial Builds server unofficial-builds#9. When that lands, I'll test this and make a release of the latest Node version. It'll be a while before a node-gyp with this change will be included in a Node release, but we can always update manually.

@richard-townsend-arm
Copy link
Contributor Author

Cool, thanks for that @joaocgreis: I'm happy for your fixups to go into into this PR.

Windows on Arm support is available in some versions of Node.js v12 and
Electron v6. This update allows node-gyp to fetch the appropriate
node.lib to build native modules. If an arm64 binary is not available
for the target node version, it's logged but ignored.

arm64 is not expected to work in very old node.lib distribution formats,
the test URLs in these cases are added to be consistent with x64.
joaocgreis pushed a commit that referenced this pull request Sep 30, 2019
Windows on Arm support is available in some versions of Node.js v12 and
Electron v6. This update allows node-gyp to fetch the appropriate
node.lib to build native modules. If an arm64 binary is not available
for the target node version, it's logged but ignored.

arm64 is not expected to work in very old node.lib distribution formats,
the test URLs in these cases are added to be consistent with x64.

PR-URL: #1875
Reviewed-By: João Reis <reis@janeasystems.com>
@joaocgreis
Copy link
Member

Tested with v12.8.0 from unofficial builds.

CI: https://ci.nodejs.org/view/All/job/nodegyp-test-pull-request/156/

Landed in 2441932

@joaocgreis
Copy link
Member

joaocgreis commented Sep 30, 2019

Published ARM64 release of v12.10.0: https://unofficial-builds.nodejs.org/download/release/v12.10.0/ (v12.11.0 has an issue with unofficial builds, fix in nodejs/unofficial-builds#10).

To use node-gyp directly from the master branch, including this PR:

npm i -g https://github.com/nodejs/node-gyp
for /f "delims=" %P in ('npm prefix -g') do npm config set node_gyp "%P\node_modules\node-gyp\bin\node-gyp.js"

rvagg pushed a commit that referenced this pull request Oct 2, 2019
Windows on Arm support is available in some versions of Node.js v12 and
Electron v6. This update allows node-gyp to fetch the appropriate
node.lib to build native modules. If an arm64 binary is not available
for the target node version, it's logged but ignored.

arm64 is not expected to work in very old node.lib distribution formats,
the test URLs in these cases are added to be consistent with x64.

PR-URL: #1875
Reviewed-By: João Reis <reis@janeasystems.com>
@rvagg rvagg mentioned this pull request Oct 3, 2019
@MehediH
Copy link

MehediH commented Jan 23, 2020

Hi, I am trying to build my Electron app for Windows 10 on ARM, but this issue is preventing me from doing so.

Firstly, I don't have a node-gyp folder in my %APPDATA/Local% directory, and the node.lib file download link meant for ARM64 leads to a 404 on this page.

Could you please point me towards the right file for ARM64 and where it should be placed for the ARM64 compilation to work as expected?

@tommyvct
Copy link

tommyvct commented Jan 19, 2021

They are way too lazy to document things down.
here is the lib.
https://unofficial-builds.nodejs.org/download/release/v15.5.1/win-arm64/

@EwoutH
Copy link

EwoutH commented Jan 22, 2021

I keep getting an 404 using node-gyp:

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

How can I instruct gyp to use the unofficial-builds?
(https://unofficial-builds.nodejs.org/download/release/v12.15.0/win-arm64/node.lib in this case)

@richardlau
Copy link
Member

Try setting --dist-url?

@richardlau
Copy link
Member

(As an aside https://github.com/EwoutH/Signal-Desktop/runs/1749166864?check_suite_focus=true#step:9:44 shows that the x64 version of Node.js is being run which is why it's looking in https://nodejs.org/download/release as the default place to look is relative to process.release.headersUrl.)

@wbsdty331
Copy link

NodeJS now officially support Windows ARM64 platform, can we reconsider this issue?
nodejs/build#2540

@cclauss cclauss added the Arm label Apr 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants