In theory we could. std and host are built for this target. We need to know by what means (cross from Windows x86_64? cross from Linux?) and for that I shall request a hint from @pietroalbini on how we build that target's rustc/cargo.

For rustc/cargo we're cross-compiling from Windows x86_64.

Cool, would you expect GH Actions to just work if I rustup target install aarch64-pc-windows-msvc and then cargo build --target=aarch64-pc-windows-msvc ? If so I should be able to add the action pretty easily.

I'm not sure exactly, I was not involved in setting that CI up. I guess trying won't hurt?

Probably wouldn't hurt, no. I'll see if I can knock up a PR to check

A brief test suggests this will be a significantly bigger job than thought.

Hyper doesn't support tokio 0.3 yet. tokio 0.2 relies on mio 0.6 - mio 0.6 relies on winapi 0.2.

I believe the fixes for aarch64 didn't make it into winapi 0.2 so we'd need to fix hyper to work on tokio 0.3 (and redo our test suite with that, which is less hassle) in order to eliminate incompatible winapi deps.

When tokio 1.0 releases, hyper intends to do a release: hyperium/hyper#2352 - In particular, hyperium/hyper#2352 (comment) suggests that we should wait for Tokio 1.0 to come out, then hyper will be updated for that, then presumably reqwest, and finally we can update. That might pave the way for this target.

It should already be possible to compile it by switching the backend from reqwest to curl. I managed to compile v1.22.1 some time ago. Didn't test it though as I'd prefer to do this kind of tests in a virtual machine and I don't run Insiders build, but maybe I'm just being too cautious 🤔

Given that Tokio 1.0 came out today I'm more inclined to wait and then update as described above.

I'm not suggesting to completely switch to curl. What I'm saying is — it can already be used to test as there's probably more to it (e.g. I know for sure MSVC detection in Cargo doesn't work on Windows arm64).

If you want to test it and submit patches for anything broken, then you can try building on/for aarch64 windows yourself. However if you think Cargo is broken currently, then it seems counterproductive for me to fight to sort CI builds out for a platform I cannot test at all and that you think won't work anyway, rather than to work on other things.

If you want help setting up a build then I can guide you, though it should be fairly easy to try:

$ cargo build --no-default-features --features vendored-openssl,curl-backend --target aarch64-pc-windows-msvc

at a guess.

Umm... Let me try to explain.

First of all, I never fought for anything. You're totally right that there is no reason to sort out CI builds if it doesn't build in the default configuration. But I never even mentioned CI, so please don't put words into my mouth.

Second, and most important, I just pointed out the fact that it can be done. I did build it but didn't test it because I was too cautious running an installer software on a real hardware as non-Insiders builds don't have Hyper-V on arm64 yet. The original question was "could we build"? I said "yes, it can be built, but...".

Third, I never said Cargo doesn't work. Again, please don't put words into my mouth. It works and I use it every day. I said there is a (known) issue with determining MSVC on an arm64 Windows. I can even tell you why is that — because Visual Studio Installer doesn't register an instance on arm64. I created an issue in Visual Studio Community but didn't create one for Cargo yet.

Honestly, now I really hope you're not part of rust-lang team, because your responses are rude and don't really motivate to help. It's not the attitude I feel comfortable with. Please reconsider.

I apologise for the delay responding, and also for how my previous comment came across. The 'fighting' was about me and CI, since the only way I have to test builds is to push them and wait for Windows CI to run on Github, and was not intended to suggest you were in any sense being combative about this.

As for 'cargo being broken', perhaps I misinterpreted what you said about Cargo and MSVC detection and for that I apologise for my wording again.

I will endeavour to improve my language. While I was very tired and stressed when I came to this issue before Christmas it is no excuse for how I came across in that comment.

If you have any suggestions for how to get things going once our dependency chain has updated to Tokio 1.0 then I would appreciate the help, I'm not a Windows-based developer by default and so I do not know the intricacies of things like the visual studio registration you mentioned.

Thank you for your response! We were all tired and stressed for the last few weeks I think. Hopefully we now have some time to recharge our batteries 🙂

For rustup, I think I could suggest the following plan:

1. I could still build rustup with curl locally and test it on my Windows arm64 machine (Surface Pro X). Since it's an installer, I expect there might be some issues with paths if for any reason anything is being written to Program Files or registry.

2. I remember there was an issue with the sys-info crate because it uses Intel asm to determine CPU clock on Windows. I know a way to solve this using WinNT API, so I'll prepare a Pull Request to that crate. But if anything, this code in rustup can be cfg-ed.

3. I don't know if it makes sense but I'll open an issue in Cargo about MSVC support. While it's not directly related to rustup, it's still nice to report it.

Unfortunately, there is still no CI/CD for Windows arm64, so the only thing that can be done is cross-compilation. Somebody will have to make sure it runs on Windows arm64, but I don't mind volunteering for now.

Thank you for being prepared to help with this. I agree that step one is to see if you can get a build up and running at all.

In point 1 you talk about issues for program files and registry, what in particular differs for aarch64 windows here? AIUI we use the user's home directory for the most part, but we do adjust the PATH environment variable (don't know if that touches the registry?)

In point 2 - Our use of sys-info is via the effective-limits crate where we care only about memory consumption. If your PR to sys-info gets caught in a non-semver-compatible version change then we'll need to PR effective-limits to get the updated sys-info too.

For point 3, yes, I agree it's important to report these things. If Cargo (or rustc?) can help with that situation then it'll improve users' lives.

For rustup, we'll likely end up cross-building for that target anyway, so here's hoping there's no significant behavioural differences which will sit "untested" per-se.

Thanks again, and I look forward to the results of your attempts to cross-build. In the meantime I'll sit tight for all our deps to update to tokio 1.0 and after that I'll start that update to rustup.

In point 1 you talk about issues for program files and registry, what in particular differs for aarch64 windows here? AIUI we use the user's home directory for the most part, but we do adjust the PATH environment variable (don't know if that touches the registry?)

I can't tell yet, I will need to check on that. Windows arm64 has 2 WoW subsystems (ARM32 on ARM64 and x86 on ARM64) so there might be some redirection when working with registry if this is how the PATH variable is changed. But for now this is just from the top of my head 🙂

reqwest v0.14 has been released today: https://github.com/seanmonstar/reqwest/releases/tag/v0.11.0

Unfortunately, rustls feature does not compile on Windows arm64: briansmith/ring#1167

Hope that this can be resolved without much trouble.

Sounds like progress is being made indeed. I will probably get a chance to work on updating rustup to the tokio 1.0 ecosystem at the weekend.

Thanks for keeping an eye out.

@Alovchin91 I've prepared a PR which updates us to Tokio 1.0 which I believe solves at least some of the winapi problems.

@kinnison Great, thanks!

I didn't try to compile it yet but given that I couldn't compile reqwest with the same feature flags because of ring dependency, I don't expect it to compile just yet. We'll probably have to wait for @briansmith to either figure out ASM support on Windows arm64, or to merge a non-ASM version 🙂

I've been too slow to make a PR in sys-info crate so its master already supports Windows arm64 😅 There's still a room for improvement though so I've also opened a new PR to fix behavior on arm64: FillZpp/sys-info-rs#82

Fantastic news, we edge closer :D

I am going to be removing this from the 1.24.0 milestone (and pushing it to 1.25.0) as I am not confident we'll get to the point of building for this platform in this cycle. If you happen to have an update on how the dependency landscape lies, it'd be handy to have it here. I believe Ring is still not quite there.

I've connected with MS on twitter - see the rust bug for the link - I think the discussion should happen there, and rustup should be doing whatever rustc ends up doing.

@rustbot modify labels: +O-windows, +A-aarch64

Hi everyone,

I have just opened a (draft) Pull Request with changes required to support Windows arm64: #2835

In fact, the only thing that's missing now is Ring but I didn't hear from @briansmith since January so I decided to go without it for now. Here's a corresponding issue: briansmith/ring#1167 I'll see if I can fix it myself but I won't spend too much time trying.

I want to do some more tests before I mark it as "ready", but so far everything looks good.
My recent changes to cc-rs have enabled detection of MSVC on arm64, and with the changes in the new PR rustup should also correctly detect the host triple it's being installed into.

Tests seem to be running fine (though I have disabled 2 tests because they need elevation; I'll run them in a virtual machine), although I've seen a bunch of tests that execute for longer than 60 seconds. Not sure what those are; I'll post full report in the PR.

Update: Run the tests, un-drafted the PR 🙂

Oops, turns out I didn't disable building ARM64 Rustup after all 😅 So now we have a working ARM64 build! 😆

If anybody's interested in trying it out, you can find it among the artifacts here: https://github.com/rust-lang/rustup/pull/2835/checks?check_run_id=3245708563

Nice! Just tried it, it works!

So it's been a year since Windows ARM64 support has been implemented, and the only thing that's keeping Rustup from releasing an official build is ring.

Unfortunately, it doesn't look like ring is going anywhere at the moment, as I've noticed that @briansmith hasn't been active on GitHub since April, and there's no sign of 0.17 release any time soon.

@kinnison Do you think it would be possible to proceed without rustls for Rustup specifically on Windows ARM64?

@kinnison Ring seems to be hardly maintained, e.g. this PR has been hanging around for 3 months now: briansmith/ring#1554

And I can hardly imagine how long it will take to update webpki afterwards.

Is rustls such a hard requirement to release rustup-init on Windows aarch64? Can we just go with the current build for now?

Just a heads up: support for Windows 11 on Parallels on Apple Silicon Macs is now official:

• https://www.theverge.com/2023/2/16/23602718/microsoft-windows-11-apple-mac-m1-m2-support-parallels-virtual-machines

• https://support.microsoft.com/en-us/windows/options-for-using-windows-11-with-mac-computers-with-apple-m1-and-m2-chips-cd15fd62-9b34-4b78-b0bc-121baa3c568c

Anybody alive here? @kinnison @rbtcollins ?

@kinnison Ring seems to be hardly maintained, e.g. this PR has been hanging around for 3 months now: briansmith/ring#1554

Sorry. I have been AFK for a long while due to factors beyond my control. From memory, I remember that reviewing and modifying that PR to be acceptable for a 0.16.x release is a lot of work. However, I recognize it is important and I will tackle it now.

And I can hardly imagine how long it will take to update webpki afterwards.

webpki is trivial update, copared to ring, since it doesn't have any target-specific code in it.

The complexity of the build.rs and the associated machinery is part of what makes ring valuable, as it has eliminated the need for cmake, perl, and many other build prerequisites. Unfortunately, the complexity has also made it very tricky to make big changes such that we can be confident that the changes won't break existing users. I will comment in the above mentioned PR about some of the difficulties I see so that the contributors can help make the review easier.

[Note: I had posted a follow-up comment to this, but I deleted it because it was intended to be posted in the ring issue, not this one.]

@briansmith Thanks a lot for chiming in! I figured that ring is not your focus at this point, so my main question right now is what prevents Rustup team from releasing an already existing version for arm64? It's a tier 2 platform anyway at this moment. @rbtcollins ?

I'm not aware of any obstacles as long as we can build an image in ci, uploading that to the upgrade servers is straight forward.

@Alovchin91 so concretely, what do you need someone else to do, to get your release made?

@rbtcollins Since everything has been building on master for more than a year now, I assume enabling CI for stable should suffice:

#3232

I cannot do anything else. Reviewing / approving / merging and publishing to the upgrade servers is on maintainers 🤷‍♂️ I'm not the one.

Thats merged; I guess we'll find out on release if more things are needed. Closing in the hope that that was it.

@rbtcollins Thanks a lot! I'll keep an eye on ring-rs and webpki releases.

Oops, turns out I didn't disable building ARM64 Rustup after all 😅 So now we have a working ARM64 build! 😆

If anybody's interested in trying it out, you can find it among the artifacts here: https://github.com/rust-lang/rustup/pull/2835/checks?check_run_id=3245708563

Are those artifacts still available? I no longer see them.