`x86_64-pc-windows-gnu/rustup-init.exe` should suggest `x86_64-pc-windows-gnu` as the default host triple

If I download this file:

https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init.exe

and run I get this result by default:

Current installation options:

   default host triple: x86_64-pc-windows-msvc
     default toolchain: stable
  modify PATH variable: yes

However if I download this file:

https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-gnu/rustup-init.exe

and run I get the same result. With GNU RustUp why is it not setting GNU ABI for
the default host triple?

[tesuji]

I think that each rustup-init.exe does the same thing is intended.
You have each one built on each Windows target.
By default rustup install msvc target if it find msvc installed.
You could override that behavior by using --default-host, example:

./rustup-init.exe --default-host=x86_64-pc-windows-gnu

I would like @kinnison or anyone to comment about this.

[kinnison]

Windows builds of rustup always default to the -msvc variant, even if they're the -gnu variant copy of rustup. This is done via https://github.com/rust-lang/rustup.rs/blob/master/src/dist/dist.rs#L148 (part of rustup::dist::dist::TargetTriple::from_host(). It might make sense to detect in there if we're a -gnu variant and pick the -gnu host triple by default, though that'd be a significant departure from current behaviour so we'd have to be certain noone was relying on it. For CI purposes, I recommend always passing --default-host xxx to rustup-init in order to be certain you're getting the right platform and --default-toolchain yyy to ensure you're always getting the right toolchain for your CI.

[retep998]

I find it weird that we still release rustup binaries compiled by -gnu. Users of rustup gain nothing by using the -gnu version and the choice of host/target is independent of which version of rustup you install. The rustup website for Windows only gives you the choice between 64-bit and 32-bit and does not expose the -gnu built version as an option.

In general, if you have VC++ installed then -msvc is going to provide a better experience due to things like C/C++ compilation actually working out of the box, which is why rustup has the defaults that it does.

Since you say the onboarding process was painful, how exactly could the rustup installation process be improved? Were your toolchain options not sufficiently explained or was it not clear how to select the toolchain?

[rbtcollins]

I think we have three separate but related issues being discussed here:
a) the rustup installation experience on windows
b) what toolchain rustup built for mingw should default to
c) how hermetic rust builds on window should be by default

Some background first - my understanding here is incomplete, but I believe that requiring the MSVC++ runtime dll is not a hard requirement for rust built binaries: its just the default behaviour. This RFC covers more detail https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md , and it has been possible since 2017 to build binaries that only link to kernel32.dll, not to vcruntime.dll. rust-lang/rust#37406 (comment)

So working back through those three issues:
c) linking in the C runtime statically is more work, and unneeded most of the time; I think its fine to default to dynamic C runtime linkage; certainly OS vendors would prefer to be able to issue bug fixes without recompiling the world - though this view is slowly changing as folk get used to more ubiquitous compute power :). Regardless; that is a discussion best had with the larger rust community.

b) there is merit to the idea that rustup built against the mingw toolchain should default to the mingw toolchain. But on balance - given rustup's job: to install toolchains on operating systems, and that even when built against mingw's libc, rustup is still targeting Windows, not e.g. Cygwin with its different VFS layer, then rustup should behave consistently. mingw here is a different compiler not a different behaviour line for rustup.

a) @cup when you installed rustup, did you encounter a missing vcruntime.dll error? If so, it would indicate that our CI / release builds are not using static CRT linkage, and given where rustup exists in the installation flow for rust we probably should do that; however I don't recall any help requests or other bugs indicating that, so don't want to assume that that is what happened.

@rbtcollins i didnt install it.

Once I got the screen with what I perceived as an error - i stopped and reported it here.

Again I will stress that i dont think its appropriate that BOTH installers are defaulting to MSVC - they should either default to their respective toolchains or we should remove the GNU altogether, as i cant see how it could produce anything but confusion

my current install method has been hacking the TAR.GZ as detailed in rust-lang/rust#60335 - with a backup as the MSI - rustup would be a good option if the issue in the OP was resolved - thanks

[rbtcollins]

@cup so per @retep998 and our wg meeting today our most likely action to resolve this confusion is going to be removing the mingw build from our downloads.

You can use rustup to configure rust for the GNU ABI - no tar hacking should be needed

@rbtcollins thats not ideal.

For new users I think the best option is to offer:

1. a ZIP file that can be downloaded
2. extract
3. write hello-world.rs
4. rustc.exe hello-world.rs

This workflow is currently not possible with Rust, as with both the MSI and
TAR.GZ, Rust has to be installed before its actually usuable. Other languages
like Go and Nim dont require this. Make it easy for new users. THEN if users is
happy with Rust at that point, they can install RustUp, as long term its a
better solution for upgrading.

[rbtcollins]

@cup setting the host is documented here - https://github.com/rust-lang/rustup.rs/blob/master/README.md#working-with-rust-on-windows (which is linked from https://www.rust-lang.org/tools/install and that is linked from https://doc.rust-lang.org/1.5.0/book/installing-rust.html).

Basically during install select the option to change the default and put x86_64-pc-windows-gnu in instead for the host.

Note also that you don't even need to change the host to target the gnu ABI if thats all you want to do - a single install on windows can target the gnu hosts - just run rustup target add x86_64-pc-windows-gnu after install. (Also documented from the first link).

[rbtcollins]

re: the idea of a zip with all the bits in it - thats an interesting idea; I'm not sure of the best forum to discuss it, its a larger topic than just rustup though - perhaps raising it in the user forums or something to get some traction around the idea might make sense

[rbtcollins]

@cup I understood your point; which is why I said that it was really a larger discussion than the rustup team; in the context of the rustup team I think the obvious thing to do is to stop offering mingw builds of rustup, as, as already pointed out here by you and others, all they do is confuse folk. I'm trying to get this ticket here to a point where we can either act on it to fix it, or decide that there is nothing to do and close it. At this point it seems like 'stop offering the binary' is the thing to do.

[Kreijstal]

I must use Mingw since msvc needs admin rights, so I rely on this

[rbtcollins]

@Kreijstal I think you misunderstand the ticket; the rustup builds you download can be built with MSVC without requiring any particular rights for as a user to use them. What you want is a gnu flavour host triple for the target toolchain that is installed, which is already and separately supported.