Change:
os: windows-latest-xl - name: dist-x86_64-msvc env: <del> RUST_CONFIGURE_ARGS: "--build=x86_64-pc-windows-msvc --host=x86_64-pc-windows-msvc --target=x86_64-pc-windows-msvc,aarch64-pc-windows-msvc --enable-full-tools --enable-profiler" </del> <ins> RUST_CONFIGURE_ARGS: "--build=x86_64-pc-windows-msvc --host=x86_64-pc-windows-msvc --target=x86_64-pc-windows-msvc --enable-full-tools --enable-profiler" </ins> SCRIPT: python x.py dist DIST_REQUIRE_ALL_TOOLS: 1 os: windows-latest-xl

Discussion:
Currently there are no native rustc or cargo binaries for Windows on ARM64. The 32-bit x86 binaries (i686-pc-windows-msvc) work correctly, but suffer a noticeable performance and battery life penalty. I've tried to build rustc myself, but have had quite a few issues trying to cross-compile it since there are no pre-built bootstrap binaries for aarch64-pc-windows-msvc. Cargo builds without issue, but doesn't make much sense without a native rustc. What would it take to get this working and available via rustup? I'm happy to keep working on this myself but am slightly lost as to how to proceed.
I've managed to cross-compile rustc, cargo and most of the default components now after fixing a build issue in a dependency (psm), but unfortunately the built compiler doesn't work. Trying to compile the default "hello world" project fails silently when using rustc directly, and cargo fails with a "STATUSACCESSVIOLATION" error, which seems to be a memory-related issue.
I have also been experimenting with this on our side! I had successfully built a rustc using older source code (April 30th nightly comes to mind), but the STATUSACCESSVIOLATION errors started happening after the stacker/psm dependency got , so I investigated that for a bit and just raised this: I think that just adding a dummy area name might solve that. I haven't tested this properly for rustc, yet, though. The latest I got to last was getting problems with my stage0 being too old to compile current head-of-trunk-nightly. I also had issues with compiling RLS due to the use of the old winapi 0.2.8, through mio 0.6.X and tokio, but this should fix itself when tokio fully updates to mio 0.7 instead of mio 0.6.X (see )
Thanks for the tip! Adding a dummy area name in has resulted in a working rustc binary. Compilation times are greatly improved in my limited testing (I've seen 40-50% reductions so far, I'll compile a few popular projects to get some accurate numbers which I'll post here).

One issue that I've noticed is that it fails to find , which the x86 rustc finds without issue (I'm working around this using the VS Developer Command Prompt at the moment). I've skimmed the relevant code and it looks like I just need to fix the dependency to use x86 tools on an ARM64 host. I'll hopefully have that done within the next few days. I noticed the same issue myself when doing an extended build, fortunately rust-analyzer works well on ARM64 when built from source and the rest of the tools (cargo, clippy, rustfmt, rust-src and rustdoc) compile fine, although I haven't tested them yet.
Regarding psm: (and our PR), so that should be good when the next deps bump happens! Agreed on , I'm basically still doing the same thing as you by using the vcvarsx86_arm64 script to set up environment variables. I have then also been experimenting with hacks on transferring those up into Powershell or MSYS2 for the run-make-fulldeps testsuite, but need to check these with people so that I'm more confident that I'm not breaking anything else in the process For changes in might be interested in hearing what you have in mind, too ;) Also, massive thank you for the contributions!
Yep, I'd just seen those fixes on and and was about to edit my comment that I'd spoken too soon! That sounds great, I'll have a look into adding support for this target to the release builders. Thanks for all your help! I'd have been lost without you pointing out that silent assembly error!
I've been working on getting the cross-build of aarch64 working so we can add it to the CI builders. alexcrichton/cc-rs fixes the failure to run the aarch64 on x8664. resolves an issue where the LLVM cross build recurses and tries to do a native build of by allowing the Rust build to specify the path to the native LLVMNM. This is not in yet. Once it is in, we can backport it to the Rust fork of LLVM. arlosi/rust has the updates to the Rust build to use the new LLVMNM option and set the flag when using (as the Rust CI builders do). I will create the PR for this once the LLVM change is in.

With all that in place, I can cross-build for aarch64-pc-windows-msvc from x8664-pc-windows-msvc from a normal command prompt with .
Hi, what's the status of this so far? I've recently bought a Surface Pro X so I would be happy to help out if I can. There are two things that I've found recently: LLVM 10.0.1 can be compiled to run natively on Windows on Arm64: LLVM 10.0.1 seems to be ready although there are no pre-built binaries available yet: has instructions on how to build Python for Windows on Arm64: These are for Windows IoT Core, but I guess they can be used to compile Python for the usual Windows as well. Would it make sense to try to build the compiler on an Arm64 machine? Also, I see there is a tracking issue to . Would it make sense to create a similar issue for aarch64 msvc windows? Additionally, would it probably make sense to try and use instead of MSVC (since the latter doesn't run natively on Windows on Arm64 yet)? Given this, plus the fact that the latest , the full development toolchain could be successfully used on Windows on Arm64.
Hi Alexander! Things are much better now that Arlo's changes have all been merged. We can easily cross-compile a native compiler and then use that in a fully-aarch64-native-build, but the MSVC toolchain (which is not aarch64-native) is still needed for the linker and the libraries. Yes it would! Especially if you plan on using the Surface as a host machine (compile on it), not just a target (compile on some x86 machine to and transfer the binary over) Also, I see there is a tracking issue to Use lld by default on x64 msvc windows. Would it make sense to create a similar issue for aarch64 msvc windows? I'm not very familiar enough with how this works to comment, but I'd guess that there's nothing wrong with creating a similar issue for aarch64 or commenting there for aarch64 support. Maybe one of the MS folks or have more insight :D Additionally, would it probably make sense to try and use clang-cl instead of MSVC (since the latter doesn't run natively on Windows on Arm64 yet)? Yes it does!

I had only tried an x8632 clang-cl at the time but native should be just as possible. This also gets around some intermittent failures when compiling LLVM with MSVC's (but this was a while back and may have been fixed now). ARM64 Python No idea! But I want to try this now. I always relied on the x8632 version. I'll paste here the ./configure options I used last time I looked at this (these generate a ). Note that an MSVC installation with all ARM64 workloads is needed for this (the installation gets auto-detected) and I was running in MSYS2-32bit (Mingw-w64 32 bit command line) with the following packages: Step 1: Cross-compile (this will take FOREVER): (that was a x8632 clang-cl from the LLVM releases but a native one should work fine, too) and then Step 2: Fully native build: and then EDIT: To update on the second one, I realised that this one won't work out-of-the-box with the MSVC auto-detection in cc-rs. Instead, it can be run in cmd in a vcvarsall environment (e.g. by running in that command line) -- but you can still generate the in MSYS2 as I wrote above. (in both cases RLS will fail btw)
Nice to see that it has been promoted to Tier 2 Development Platform! However, how can it be used? When I try to install it using rustup-, I get an error that there is no such platform:
I think similar to , the list needs to be updated.
I can submit that now
Oh, logged in to do just that Please go ahead