Rustup: MSVC tools installation requires manual intervention by users

Created on 16 May 2017  路  6Comments  路  Source: rust-lang/rustup

I don't know how to reopen an issue to have raised it as a new issue.

Rust 1.17.0 doesn't seem to have improved the Windows user installation experience. I downloaded and ran the rustup-init.exe and it gave me a console with a big red warning that I needed to install C++ build tools before proceeding. For me one of the whole points of using Rust is so I don't depend on the C/C++ ecosystem. Anyway, it gave a link to the needed build tools and I got their installer and that didn't work saying I needed .Net 4.5.1 or some such and I decided not to go round that loop again. (I do have Mingw64 installed but have no idea how to tell the Rust installer about it. I tried the 'custom' install option but when it asked for the 'default host triple' I could guess it wanted x86_64-pc-windows- but not what the end should be, so once again I've given up for now. Windows users generally expect things to just work: compare with Go's installer which is easy and fast and works.

O-windows

Most helpful comment

Dropping the dependency on the VC++ build tools is not feasible or desirable. Compiled languages need a linker, and the VC++ build tools are how you obtain microsoft's linker.

If you don't want to use the microsoft linker, rust also supports the -gnu toolchain, using mingw's ld linker. AFAIK, until llvm's linker matures, these are the only two widely used, fully-featured linkers that are capable of producing PE files.

Note that go avoids this problem by implementing their own custom linker for each platform, and implementing their standard library on top of raw system calls. This linker is specifically for linking go programs, and while it does support limited linking of C libraries as well, it is not a full linker, and so eg. cannot statically link to C++ libraries. This would be something of a show-stopper for rust, not to mention completely out of scope due to the volume of work that would be required.

If you choose to use the -gnu toolchain, you don't need mingw installed at all - the mingw linker is packaged with rust, and will just work with no additional setup. The problem with this setup is that most rust devs still depend on C libraries (for example, the curl, openssl, etc. crates are widely used), even if it's indirectly, and the version of mingw that's packaged with rust, does not include a C compiler. You will run into this exact same issue if you try to use go on windows, and depend indirectly on a C library.

This has basically been a list of things we can't do. Here's what we could do:
1) Improve installation instructions for VC++ build tools, perhaps even download the installer automatically.
2) Improve the "host triple" selection process, so that you pick from a list, rather than typing it in, and also make it obvious which hosts are applicable for your system.
3) GUI installer - this is already on the roadmap, and should be a bit more familiar for most users.
4) ?

A significant difficulty is the selection between the msvc vs gnu toolchains. It's an important decision, but it's difficult to inform the user on how to make that decision.

All 6 comments

Dropping the dependency on the VC++ build tools is not feasible or desirable. Compiled languages need a linker, and the VC++ build tools are how you obtain microsoft's linker.

If you don't want to use the microsoft linker, rust also supports the -gnu toolchain, using mingw's ld linker. AFAIK, until llvm's linker matures, these are the only two widely used, fully-featured linkers that are capable of producing PE files.

Note that go avoids this problem by implementing their own custom linker for each platform, and implementing their standard library on top of raw system calls. This linker is specifically for linking go programs, and while it does support limited linking of C libraries as well, it is not a full linker, and so eg. cannot statically link to C++ libraries. This would be something of a show-stopper for rust, not to mention completely out of scope due to the volume of work that would be required.

If you choose to use the -gnu toolchain, you don't need mingw installed at all - the mingw linker is packaged with rust, and will just work with no additional setup. The problem with this setup is that most rust devs still depend on C libraries (for example, the curl, openssl, etc. crates are widely used), even if it's indirectly, and the version of mingw that's packaged with rust, does not include a C compiler. You will run into this exact same issue if you try to use go on windows, and depend indirectly on a C library.

This has basically been a list of things we can't do. Here's what we could do:
1) Improve installation instructions for VC++ build tools, perhaps even download the installer automatically.
2) Improve the "host triple" selection process, so that you pick from a list, rather than typing it in, and also make it obvious which hosts are applicable for your system.
3) GUI installer - this is already on the roadmap, and should be a bit more familiar for most users.
4) ?

A significant difficulty is the selection between the msvc vs gnu toolchains. It's an important decision, but it's difficult to inform the user on how to make that decision.

I am not arguing against the MS tools ideologically. I'm just saying that on Windows a rust install should "just work". If that means bundling or downloading MS tools that seems fine to me. However, on my Win 7 system that won't work 'cos as soon as the MS tools installer runs it says it won't work without .Net 4.5, and when I install that it asks for something else etc. So I'd be surprised (but delighted) if you could cover all such cases for all supported versions of Windows.

Perhaps another approach would be to detect whether the MS tools are already installed and if they are make use of them. And if they're not offer to (1) install whatever GNU tools would do the job (including C compiler) so that the install will work in a complete and self-contained way, or (2) offer to attempt to install the MS tools, or (3) recommend the user install the MS tools -- with links to where they are and then that they retry.

This way, people who just want to learn rust on Windows and already have the MS tools will get a workable install, and so will those who don't have the MS tools but do accept option (1).

I had the very same problem and could solve it thanks to @Diggsey by replacing -msvc with -gnu. I agree that the Rust installer for Windows, after it detects that the MSVC Build Tools are not installed, should default to -gnu instead, so at least the user gets a working installation. Currently the installer shows a big warning and if one presses ENTER it installs nonetheless, but later rustc will fail to link the executable.

Disclaimer: I'm a Rust newbie and I do not see the benefit of installing VS just for the linker... it is a 5 GB download!

To close this we basically need to:

[] contact microsoft and establish a well known download endpoint for the MSVC toolchain components we need
[] then use that to download and launch the installer for them

If someone wants to get in touch with MS's dev-rel team and start this conversation, I think this bug is probably just-about clear enough to do so, but would benefit by linking to the relevant message that we display and describing the tooling we need in more detail.

Hello!

It might be interesting to note that VS has supported a "guaranteed install path" for command line usage for some time, and to allow grabbing specific components as needed. Information can be found here

With the Build Tools components (the command line focused ones that doesn't install all of Visual Studio) listed here, rustup could do a minimal install on fresh environments.

IIRC npm (or at least some npm related tool) does this to a degree when no toolchain of any kind has been detected on the system. 馃檪

After installation, rustup should be able to grab information from vswhere, which also shows ways to load the msvc compiler toolchain into a more 'sealed' environment (e.g., link.exe wouldn't need to be on the PATH).

@rustbot label: +O-windows

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mcandre picture mcandre  路  4Comments

lilred picture lilred  路  3Comments

jjl picture jjl  路  3Comments

fenhl picture fenhl  路  4Comments

KasMA1990 picture KasMA1990  路  3Comments