-
Notifications
You must be signed in to change notification settings - Fork 30k
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
Support ARM64 Windows desktop #25998
Comments
What's needed from GYP? |
OpenSSL config PR: #26001 |
@refack, here you go: refack/GYP3#23 |
refack/GYP3#23 also submitted as #26020 so it can be merged sooner. |
FYI, @jkunkee the ARM64 change for ICU is here: unicode-org/icu#412, and the ICU issue/ticket is: ICU-20382. |
(progress-tracking comment updated) |
For those interested, my hope is for Electron 6 to support Windows 10 on ARM (natively, not via emulation). electron/electron#16876 |
[EDIT: merged info into earlier comment] |
This adds ARM64 Windows support in the OpenSSL build system. Since OpenSSL's ARM64 Windows support does not have support for ASM-- that is, VC-WIN64-ARM inherits from VC-noCE-common which has no ASM files--`openssl_no_asm.gypi` is always used for building. This essentially forces the 'no-asm' Configure flag. PR-URL: #26001 Fixes: #25998 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sam Roberts <[email protected]> Signed-off-by: Beth Griggs <[email protected]>
This change adds the generated files required for building OpenSSL for Node.js for ARM64 Windows. I did this on a VM running Ubuntu 18.04. The basic workflow is to cd to deps/openssl/config and run `make`, installing any needed packages until all architectures build correctly. Note that OpenSSL 1.1.1 does not support ASM on ARM64 Windows, so this change also supports only no-asm on ARM64 Windows. PR-URL: #26001 Fixes: #25998 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sam Roberts <[email protected]> Signed-off-by: Beth Griggs <[email protected]>
This adds ARM64 Windows support in the OpenSSL build system. Since OpenSSL's ARM64 Windows support does not have support for ASM-- that is, VC-WIN64-ARM inherits from VC-noCE-common which has no ASM files--`openssl_no_asm.gypi` is always used for building. This essentially forces the 'no-asm' Configure flag. PR-URL: #26001 Fixes: #25998 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sam Roberts <[email protected]> Signed-off-by: Beth Griggs <[email protected]>
This change adds the generated files required for building OpenSSL for Node.js for ARM64 Windows. I did this on a VM running Ubuntu 18.04. The basic workflow is to cd to deps/openssl/config and run `make`, installing any needed packages until all architectures build correctly. Note that OpenSSL 1.1.1 does not support ASM on ARM64 Windows, so this change also supports only no-asm on ARM64 Windows. PR-URL: #26001 Fixes: #25998 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sam Roberts <[email protected]> Signed-off-by: Beth Griggs <[email protected]>
The toolchain for ARM64 Windows includes support for assembly code, but with a very different syntax from MASM and NASM. This change teaches GYP how to emit the right XML tags in VCXPROJ files to support compiling assembly files with the new tool. PR-URL: #26020 Refs: #25998 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: João Reis <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>
This adds ARM64 Windows support in the OpenSSL build system. Since OpenSSL's ARM64 Windows support does not have support for ASM-- that is, VC-WIN64-ARM inherits from VC-noCE-common which has no ASM files--`openssl_no_asm.gypi` is always used for building. This essentially forces the 'no-asm' Configure flag. PR-URL: nodejs#26001 Fixes: nodejs#25998 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sam Roberts <[email protected]> Signed-off-by: Beth Griggs <[email protected]>
The team is waiting for machines they can use in their CI: nodejs/build#2540 For anyone who's interested, you can build NodeJS ARM64 yourself today by doing the following:
Currently, Windows ARM64 is "guaranteed to build" as it's in Tier 2 for compiling: https://github.com/nodejs/node/blob/master/BUILDING.md#strategy - so this should work without problems in future versions as well. Here's a recent 16.13.0 build from a few days ago: https://github.com/dennisameling/node/releases/tag/v16.13.0-arm64 |
you great a great grreat contributor i see you everywhere windows should pay you for all the work and advancement you have done for windows on arm keep it up! you inspire |
any plans on this? seems like its time |
I believe obtaining build agents should now be much more easier thanks to Arm-based processors coming to Azure: https://azure.microsoft.com/en-us/blog/now-in-preview-azure-virtual-machines-with-ampere-altra-armbased-processors/ If needed I can provide a part of my subscription to host the required VMs. If you need to get in touch with me regarding this, please reach out at: [email protected] |
@dennisameling Thank you for the notes! I was able to install wix 3.14 and added a path variable for WIX, but I'm wondering if there are any other environment config steps I should be aware of? I'm getting the following error running the script:
and I'm afraid to dick around with vcbat much further since (I believe) VS 2022 is the first version to support arm64. The error seems to be tied to VCINSTALLDIR being null; do you have any idea what might be going wrong? Edit: The same thing happens whether I try running from cmd, a developer prompt launched by visual studio, git bash, or power shell. |
@nonsenseless Which VS version do you have installed? We've built it with 2019 without problems so if you have that and it's not detected that would be a problem (VS2019 what's on our build machines) |
Not sure whether ARM64 differs, but on x64 you need both the Wix Toolset and the WiX Toolset Visual Studio Extension (we're using the VS 2019 version in our CI). |
@richardlau I went back and I realize that when I tried to install VS2019 and it gave me a stability warning about not being supported on ARM64 I interpreted that as "You can't install this" instead of as "Good luck". I pressed through, installed, added the wix extension for 2019, and then the build steps worked for the version I'd pulled down. Thank you for your help! |
I'm happy to hear you're making progress, @nonsenseless!
Got there in the end. The VS team would have worded that carefully to help forestall perf and functionality bugs that their dev and triage processes was not equipped to handle. "Good luck" is the right interpretation, though it could also be seen as "yes, we know it's slow, no, it's not a bug" or "we won't chase down broken corner cases if there are any." The goal of the x86 and x64 emulators is that apps--even ones as complex as VS--just work, unmodified. :) As you've figured out, VS 2022 is the first to officially support running on ARM64. On ARM64 Windows 11 (which has the ARM64 and x64 .NET Frameworks as well as x86), devenv.exe, msbuild.exe, cl.exe, csc.exe--everything runs natively without emulation. (You can use varargs.cmd to force the use of x64- or x86-hosted tools just as on x64; they'll just run slower.) IIRC, VS has supported generating ARM64 code officially since VS 2019, with experimental support introduced later in VS 2017. (I believe I used VS 2017 to bootstrap the Node.js build for ARM64 Windows.) VS 2022 is also getting support for ARM64EC, an emulation-compatible native ABI. There are some fun possibilities here for Node.js (think native ARM64 JIT with x64 binary module compat), but they are neither trivial nor salient to this thread. :) |
Needed for ARM, which is presently not supported by prebuildify due to lack of official node builds: nodejs/node#25998
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment. For more information on how the project manages feature requests, please consult the feature request management document. |
Nope, not so fast! By now you have everything in place to implement this. |
fixed per @eukarpov #46231 (comment) |
Note that in terms of activity on this front, most of the discussion has been happening over in nodejs/build#3046 and it is being built as part of our regular CI runs - it just hasn't made it to being a production release platform yet. |
Refs: nodejs/build#3046 Refs: nodejs/build#2540 Fixes: nodejs#25998
Refs: nodejs/build#3046 Refs: nodejs/build#2540 Fixes: #25998 PR-URL: #47233 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Refs: nodejs/build#3046 Refs: nodejs/build#2540 Fixes: #25998 PR-URL: #47233 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Refs: nodejs/build#3046 Refs: nodejs/build#2540 Fixes: #25998 PR-URL: #47233 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Refs: nodejs/build#3046 Refs: nodejs/build#2540 Fixes: #25998 PR-URL: #47233 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Is your suggestion related to a problem?
At present the Electron project does not support the new Windows 10 on ARM (ARM64 Win32) platform. One of its dependencies is Node.js, which also does not support it. This means that on these devices Electron apps run emulated which, with the complexity of Electron, means a suboptimal user experience.
Describe the solution you'd like
I would like Node.js to support Windows 10 on ARM. Ideally this would include any tweaks needed to make Electron embedding easier, and I would be pleased as punch to see Node.js host ARM64 Windows EXEs on its main page.
Describe alternatives you've considered
As mentioned earlier, Windows 10 on ARM includes an IA32 emulation layer that runs Node.js. This works well for many applications, but my prototype ARM64 build of Node.js runs much faster in significantly less memory.
The text was updated successfully, but these errors were encountered: