Why do I need Microsoft C++ build tools?


#1

image

Why do I need Microsoft C++ build tools in order to install the Rust Compiler?


Which one of these do I install?


#2

Because you need a linker. (Edit: import libraries and other tools like rc, too.)

Probably “Desktop development with C++” since it contains “the Microsoft C++ toolset”.


#3

“Compiler” is unfortunately a bit of an overloaded term. It technically refers to only the first tool in the “toolchain” used to build what’s called a “native binary” for a given platform. However, “compiler” is often used as a shorthand to refer to the entire toolchain.

A native binary is a file that can be executed by a particular operating system on a particular piece of hardware, without the aid of an interpreter or VM. C, C++, Fortran, and Rust (among others) are typically compiled into native binaries; Python, for example, is not, so it relies on the program python.exe (itself a native binary) to run on Windows.

The “Rust team” actually relies on a variety of “backends” (build toolchains) to take the intermediate code generated by the Rust compiler (the “frontend”) and generate native binaries. On Windows, this can either be the Microsoft-provided toolchain (the default) or MinGW (a toolchain that, for lack of a better explanation, allows programs to run in a more “Linux-y” environment).


#4

Yes, confirmed. Also, for anyone reading this thread who doesn’t want to run the MSVS installer, the required toolchain components can be downloaded and installed separately via the first link printed in the alert message in the screen capture in the original post.


#5

Not really. MinGW is a port of the GNU toolchain that targets Windows, and the Win32 API, for writing Windows software. The reason MinGW and MSVC are separate targets is because MinGW does a not-that-great job of being a Windows toolchain. It’s incompatible with MSVC import libraries, the import libraries is does provide are old (and in many cases, flat-out wrong), and it doesn’t use the same runtime libraries as MSVC code. I’m also not sure if GCC is ABI-compatible with MSVC; I know that clang isn’t.

The practical upshot of this is that, barring simple cases, MSVC and MinGW-compiled code, whilst both running on Windows through Win32, aren’t entirely compatible with one another. So if you’re linking against libraries built with MSVC, you have to use the MSVC backend, and vice-versa for libraries built with MinGW.

The “UNIX-y environment” toolchain on Windows is Cygwin, which does everything it can to paper over Win32 to create as UNIX-y an environment as it can, to make it easier to build UNIX software for Windows. MSYS is a fork (?) of Cygwin that provides a UNIX-y environment for building Windows software… and for building UNIX software for itself.

The above is a complete pig’s breakfast of a mess, which is why I try to avoid mentioning it because almost none of it is important for Rust users beyond: “there’s MinGW and MSVC, just use MSVC unless you can’t”.


#6

My phrasing was a pathetic attempt to try to gloss over those details, partly to hide my own ignorance and partly to avoid talking about Cygwin and MSYS. But, yes, “Linux-y binary interface” may have been a better thing to mention than “Linux-y environment”.

And I didn’t even mention the WSL…though arguably nothing running there even counts as a “Windows toolchain”.


#7

Even then, it’s not that it’s a “Linux-y binary interface”. It’s not even entirely correct to say it’s a “UNIX-y toolchain”, since UNIX doesn’t use import libraries in the first place. There’s nothing particularly “Linux-y” about it, it doesn’t really behave quite like a UNIX toolchain, and it isn’t quite compatible with the native MSVC toolchain… perhaps a more accurate summation would be “a GNU toolchain for Windows by way of Google Translate from English to Chinese to German to Japanese and back to English”.

It’s probably best to just avoid talking about MinGW wherever possible; damn thing gives me a headache.

WSL is pretty much a half-way house between Cygwin and a VM: all the disadvantages of a VM (isolated environment) and all the disadvantages of Cygwin (imperfect compatibility) rolled into one convenient package! :stuck_out_tongue:


#8

Well, technically, you’re right, but for practical purposes (and at a level of detail accessible to the OP), the only reason to choose MinGW over the native toolchain is for compatibility with other MinGW-ABI binaries, and those are almost universally *NIX-y (and “Linux-y” is the most beginner-friendly way I know of to say that).

What do you actually dislike about WSL from a practical standpoint? I quite like it so far, although I haven’t had much opportunity to use it.


#9

Well, there’s also compatibility with libraries that simply don’t compile with MSVC in the first place, or where compiling with MSVC is not supported. I recently tried to build something, and it basically told me “we don’t support MSVC, use the GNU toolchain”; forget what it was for.

Also, the ABI thing isn’t necessarily because the source code won’t build with MSVC; it could be that you were given a precompiled library that was built with MinGW.

But that quote was specifically just about the “UNIX == Linux” conflation. Anyway, this is getting really off-topic now.


#10

Its actually a dead link the first link so I have to download the entire thing :frowning:


#11

Isn’t it possible to use gcc/g++ compiler instead?


#12

That’s what the GNU target uses. This is for the MSVC target. To quote myself:


#13

http://landinghub.visualstudio.com/visual-cpp-build-tools

Hey man, this link appears to be dead. Is there an alternative link I could use to download this?


#14

If you’ve already got the VS installer, you can just install through that.


#15

When I selected the desktop version then I have to download around 2 GB worth of crap and I have a slow Internet connection. Isn’t there a way to just install what I really need, not those extra crap?


#16

I don’t have a Windows machine to verify, but some quick Googling finds this link which appears to have a link to the build tools.


#17

@lambda’s link looks correct to me.

Once you’ve verified that the tools there work for you, @Joe232, could you please submit an issue to the Rustup repository?


#18

Thanks for your help :slight_smile: it works


#19

Yeah sure mate, but one thing, if the tools work, what issue should I submit to Rustup repo?


#20

That the link in the message is stale, and needs to be replaced with the working link. (Please include the working link, and possibly a link to this discussion.)