After it stopped doing many things (and it didn't throw any errors, so I guess it was successful), I end up with a "build" directory that contains various build artifacts.
But the only thing I can find in there, that is somewhat related to "win7", apparently is: build\host\stage1-std\x86_64-win7-windows-msvc\release
This directory contains a std.dll as well as libstd.rlib and libcore.rlib
There also is a rustc program, but it does not seem to be a "win7" version: build\x86_64-pc-windows-msvc\stage2-rustc\x86_64-pc-windows-msvc\release\rustc-main.exe
Now, where do I go from here ???
Is it complete yet?
And, if so, how do I actually build my Rust app with the "win7" tool-chain?
What I need is that cargo build --target x86_64-win7-windows-msvc will work
Thank you for any advice!
(I'm building on Windows 11 with Visual Studio 2022, Python 3.14 and Git installed)
If you just want to build your application for Windows 7 then you don't need to build the compiler itself, you just need to use nightly and the build-std feature.
Building rustc itself is more involved. If you really do want to do that then it's probably best to follow the rustc dev guide for learning how that works. Note that there can be a difference between a "host" and the "target". If you're running on Windows 11 then it's fine for the host to not support Windows 7 Only the target needs to support Windows 7 so the application you build is compatible.
Why the instructions for *-win7-windows-msvc target don't mention that?
Anyway, is there a way how I can do this with "stable" Rust?
I usually do my builds automated on my CI/CD server. Because I want the builds to be reproducible (and not fail randomly), I use a specific "stable" Rust version in my CI/CD build script and only upgrade to a newer version every now and then. But, if I need to use the +nightly toolchain, then it will use the latest "nightly" every day, which smells like trouble
The problem with this guide is that it mentions so many things that could or might be done. But there is no simple complete but minimal example how to build a "ready to install" Rust tool-chain for a specific target (e.g. *-win7-windows-msvc) from the sources without thrills and bells and whistles. Would you mind pointing me to a complete but minimal example?
Yes, sure, but that turns a stable compiler into a nightly for the purposes of bootstrapping. It is no longer a stable compiler. And it is not supposed to be used outside of bootstrapping.
A better way is for more people or organisations to sign up for maintaining the win7 targets and request that they become tier 2. Once a target is tier 2 it is made available for download via installers such as rustup.
An even better way might be something like my target_version RFC. That would allow targeting different minimum versions of Windows without needing a different toolchain. But it's not likely to arrive on stable anytime soon (and it wouldn't avoid the need for having win7 maintainers).
I would say that if you want to build anything shipable using unstable features it's still better than using nightly. Purely because of reproducibility. Especially if that's for something that requires ancient tools: if that thing is Win7-based today then it's for something long-living… and chances of finding a copy of stable compiler 10 years down the road are much higher than chances of finding a particular fixed nightly build.
Even if, technically, it's no longer supported (but then win7-windows-msvc is tier3 anyway thus support is moot point).
There is no nightly corresponding to a specific stable release. Every 6 weeks beta branches off from nightly (often in the middle of two nightly releases) and then for the next 6 weeks we backport fixes to the beta branch before it gets promoted to stable. That is 6 weeks of divergence from any specific nightly. But if you want to know the nightly before it got branched off, you can do git merge-base master <the commit shown in rustc -V> in the rust repo and then check which day this commit is from. If this commit directly corresponds to a nightly release, then you need the day after the commit as nightly. Otherwise you need the day the commit was made on.
So, if I pick the nightly just before the fork, I might be missing the fixes that got backported into "beta" before the "stable" release. And if I simply pick the nightly from the date of the "stable" release, there may be some additional divergence already. Both doesn't sound like great options. So, I will see how far I can get with "stable" and the RUSTC_BOOTSTRAP trick.