I have been interested in Rust for a long time, and some time ago I decided to pick it up again and install on my Windows 10 PC. I downloaded the installer, then I noticed that Rust has switched to rustup instead of an installer like before. By default it offered me to use the MSVC toolchain, which I thought nice on Windows.
However, that's where my problems started. First, I needed to install the build tools. The Visual Studio itself is a huge monster, so downloading and installing it is something that I would obviously like to avoid. Therefore, I decided to go with the Visual C++ Build Tools. I installed them, tried launching cargo, and it couldn't compile my project and told me, "'link.exe' was not found". After searching the web, I found out that I need to run vsvarsall.bat, which unfortunately did nothing useful to me.
Finally I gave up and simply added link.exe to my PATH. That helped, but not much, because now I got the following complaints: "LINK : fatal error LNK1181: cannot open input file 'advapi32.lib'". Unfortunately, I couldn't fix that, so the only thing left for me to do was to revert to the GNU toolchain, which started working perfectly like all Rust setups on Windows I had before. I don't know what I would do if I didn't know that I can choose a different toolchain on Windows which doesn't need such a wonky setup.
Basically, I have two questions. The first one is obvious: what could I have done wrong to get the toolchain up and running? The second one is something that worries me more, how can the process of setting it up be improved? Maybe this forum is the wrong place to write about this, but if a determined user like me can't get the default chain to run, what chances do the novices have?
According to the new shiny roadmap for 2017, one of the main goals for this year is to provide a better learning curve. This just won't be possible to do if the steps to get the stuff up and running are so difficult. Again, if I'm writing to the wrong place, please direct me to the right place to say something about this.
Until @retep998 can show up and clarify (since if anyone knows what's up, it'd be him):
rustc knows how to find the VC++ build tools without needing vsvarsall.bat (or anything similar). If it can't find LINK.EXE, then the most likely problem is that you've installed a new version that has (once again) changed where it tracks the install location, meaning Rust can no longer find the tools to use them correctly.
This all usually just works, and works better than it does for people trying to use C++. I know there've been issues in the past when Microsoft just changes where it keeps registry keys and making everything sadness and misery.
The only thing I can think to suggest is running Rust from inside a VC++ command prompt, started from the appropriate start menu shortcut (correct host and target platform, too).
First I need to know which version of VS you installed. If you installed VS 2013 or VS 2015 (with the C++ option which is disabled by default) or the VC+ build tools, then rustc should be able to autodetect it just fine. If it doesn't, I'm going to need a lot more information about your setup so I can diagnose how exactly your installation is weird so I can either fix your setup or fix the handling of that corner case.
If you're using VS 2017, there is no autodetection because it uses a completely different method that rustc doesn't know yet. You'll just have to use the appropriate vcvars bat file. Open up cmd. Do call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat" (or vcvars32.bat if you're using the i686 toolchain, which you really shouldn't be using if you can help it) (also possibly adjust the path if it is different for you), and then you can do your rust stuff as normal. Eventually someone will implement support for VS 2017 and things will be simple again, most of the time anyway.
Install the vs 2015 build tools and restart, the path your compiling from might not see the new tools when linking until you restart at least the command prompt.
I installed the Visual C++ 2015 build tools, all options were unchecked during the installation. I did run vcvars64.bat, also vcvarsall.bat amd64, but that didn't put link.exe on my PATH, nor did it solve the library problem. If you need more information regarding what is not working here, I'm glad to provide it.
@DanielKeep Yep, I could do that, but even then it's not helping much since I get the library error I described. Besides, I can run cargo from the command line, but I can't really tell the IntelliJ plugin to do that.
@viperscape Of course, I did all of that. In fact, I'm writing about this problem a couple of days later, and the state of affairs is still exactly as it although my PC has been turned on and off several times by now.
Adding link.exe manually to your PATH won't work because there's a lot of environment variables that have to be set correctly for MSVC to work properly. If you installed the VC++ 2015 build tools and running "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\vcvars64.bat" does not add link.exe to your PATH (along with the other env vars) then something is very wrong. Can you dump your environment variables both before and after running that bat file? Just enter set and it'll dump everything for you.
If you installed the VC++ 2015 build tools, then it will have automatically installed some version of the Windows SDK. I don't think it will let you skip all of them completely. If it does that seems like a rather stupid design flaw in the installer.
OK, so I modified the build tools installation to include the Windows 10 SDK, and now everything seems to build fine. link.exe is still not in my PATH, but fortunately Rust doesn't seem to have a problem with that anymore, which is nice to see.
I think we should probably add this information somewhere in rustup regarding how the Visual C++ tools should be installed, because it is apparently perfectly possible to install the tools without them and have all the problems I had. There is also the Windows 8.1 SDK in the bundle, not sure if it would have worked in my case.
The default installation of VC++ 2015 build tools include the 8.1 SDK, but it is possible to install without any SDK, which I did myself a few days ago, resulting in the same problem.
$&%@^# - same problem, same solution. I suspect this is relatively common, since I personally assumed that, since I wasn't developing a Windows 8/10/etc application specifically, that I could simply not install those bits.
It certainly does, which is quite daft. Not sure there's a lot Rust can do about it, apart from saying "STAY AWAY FROM WINDOWS"...
Rust could have more detailed instructions on how to make sure you have VC++ installed correctly, along with a troubleshooting FAQ to cover these various problems.
Precisely, this is one of the reasons I wrote here about this problem. I bet a lot of people will make this mistake too when installing Rust for the first time and simply turn away from it. Previously it wasn't a problem with GNU tools, but now MSVC is the default, so we should make sure that the process is as seamless as possible.
I managed to install and compile using latest nightly, stable might also run, with VC++ 2017 build tools, a detailed installation instructions can be found here
One problem with the Rust Windows experience is that multiple install steps are documented incorrectly.
The link from the official Rust installer page to "Microsoft Visual C++ Build Tools 2017" does not actually land on a download for these build tools, but rather the generic Visual Studio homepage. Of course, that page does not make it easy to find the build tools, but that's not something that the Rust community can control. What we can control is fixing our broken link (if a working one can be found), or better yet, providing much more detailed instructions for installing the Visual Studio components required to use Rust.
The official Rust installer page also gives completely generic instructions for selecting the appropriate Visual Studio components to run Rust in Windows: "C++ tools". There is no such component named "C++ tools", though there are quite a few C++-related components. Which one of these is actually the one that users should install? Is this the "Desktop development with C++" workload?
The Rust GitHub issue tracker claims to support Visual Studio 2017 as of Rust v1.19, though in fact, cargo install xargo with Rust v1.23 complains:
note: the msvc targets depend on the msvc linker but `link.exe` was not found
note: please ensure that VS 2013 or VS 2015 was installed with the Visual C++ option
So there is a disconnect between what the command line cargo utility claims to support (Visual Studio 2013, 2015) vs. what the Rust installer webpage claims to support (Visual Studio 2015, 2017).
Another important ambiguity: Are Windows users expected to A) manually add the directory containing link.exe, cl.exe, etc. to the PATH environment variable B) always launch rustc, cargo, etc. from a Visual Studio Command Prompt session using the silly .BAT files for this, or C) depend on the Rust system to automatically discover where the Visual Studio files are located?
The page the Rust site links to does include a download link for the "Build Tools for Visual Studio 2017," if you scroll down. The naming and URL fragment could be updated on the Rust site, but they will also probably change again so maybe some indication that you can scroll down is in order.
Provided you download the vs_BuildTools.exe installer rather than the generic IDE-including vs_community.exe from the top of the page, there is a workload called "Visual C++ build tools," and only two others for web and .NET Core. If you do use vs_community.exe, then the correct workload is "Desktop development with C++."
Rust 1.23 does support VS 2017 out of the box (I just tested it). If that error message is still around it should be updated, though if it's still showing up even when you have the build tools installed it probably needs to be changed in a different way.
Windows users are not expected to update PATH, or use the Developer Command Prompt, or call the .bat files themselves- "support for VS 2017" means rustc knows how to find it on its own. (When VS 2017 first came out, running in the Developer Command Prompt or calling the bat file were workaround solutions; they are no longer necessary.)
Recently I did a clean install of my computer and i'm having the same issue.
I have the 2017 build tools (15.7.3) installed, following the documentation, but link.exe cannot be found.
error: Could not compile `bitflags_derive`.
warning: build failed, waiting for other jobs to finish...
error: linker `link.exe` not found
|
= note: Het systeem kan het opgegeven bestand niet vinden. (os error 2)
note: the msvc targets depend on the msvc linker but `link.exe` was not found
note: please ensure that VS 2013 or VS 2015 was installed with the Visual C++ option
error: aborting due to previous error
I have a feeling modifying the toolchain through the Visual Studio Installer (which comes with the build tools) will solve the problem. I will update after i tried it.
EDIT: It works now by Installing the Visual C++ build tools, as mentioned before.
I also tried combinations to find the minimal working set of individual components but that still resulted in the same build error.
..although link.exe was available using varsall.bat, with the following components installed
Static analysis tools (Code tools)
VC++ 2017 Version 15.7 v14.14 latest v141 tools (Compilers, build tools, and runtimes)
Visual Studio C++ core features (Development activites)
The amount of necessary components could possibly be smaller, i haven't permuted through them all. The default component set totals around 1.8 gigabytes of installation space.