rustup does not recognize Visual C++ Build Tools #1003
Comments
|
Installing Visual Studio 2017 for C++ Desktop Development makes it work. Perhaps specifying installing VS with C++ is the safer bet. |
|
@projektir I got this issue. I have tested many custom installation settings of Visual C++ 2015 Build Tools installer. Install Visual C++ 2015 Build Tools with the DEFAULT installation will solve this problem 😄 and remember to re-proceed the installation with rustup-init. It may affect the linker. Edit: rust requires Windows SDK (8.1 or 10 is ok). Another test: #1003 (comment)
After that, I encountered this linker issue: rust-lang/rust#30319 I have tried to install "Visual Studio 2017 for C++ Desktop Development" as suggested, but it still not work, and rustup doesn't recognize Visual C++ Build Tools. Again, I have tested VS 2017 installer by adding more components related to C++ development, also try to strip as much as possible. Here is the required components to install Visual C++ via Visual Studio for Rust HelloWorld program:
rustup still requires VC++ 2015 toolset, Universal CRT SDK & Windows 8.1 SDK to recognize the build tools. Therefore, I removed all VS 2017 related programs and re-install Visual C++ 2015 Build Tools with the DEFAULT settings for my Rust HelloWorld program. My linker issue is no longer happen anymore. I don't know why? Maybe, VS 2017's installation fixed it? I have tried to reproduce the linker problem by removing all and install again, but it has been disappeared. What a horrible getting started experience with Rust on Windows! |
|
@redstrike so happy to see that someone else ran into this! Thanks for describing this in such detail.
I very much had a similar approach that I think was causing issues. I kept trying to strip down what I was installing since I didn't really need much from VS on my machine. Among other things, I get a weird feeling that the Windows SDK is required (and you have it selected in your list), which just doesn't make much sense to me. I may experiment a bit more and see if I can confirm that. If we can figure out what exactly is needed for install, we could update the README.md. Seems like C++ 2015 Build Tools with DEFAULT settings (lol) is a good safe bet, but would also be nice to know how VS can be installed since many will have that on their machine. |
|
@aturon I'm not quite sure what you have in mind, beyond changing the documentation, nor why you consider this particularly troubling? The fact is, rust currently requires (and has always required) all three of these components, and the components are installed by default when installing the VC++ build tools. If you remove those components it can't work. I can add a note the installation instructions saying to use the default settings, but anything more detailed, such as exactly which components are required, may be difficult to keep up to date and correct for all versions of the installer, since MS have a tendency to change things up quite a bit! Here's a breakdown of why each component is required:
@projektir @redstrike Is there something further you'd like to see changed? |
|
It doesn't really matter which VC++ toolset version you use, or which Universal CRT version you use, or which Windows SDK version you use as long as you have all three of them. However, it is generally better to have the newest versions when possible. If you install VC++ via VS 2017, then Rust is currently incapable of autodetecting this VC++ installation, and you'll have to manually configure your environment using a vcvars bat file or the VC++ development command prompt option. |
|
I was just about to jump in here to say
👍 we have people hitting this every day now. |
|
Here's the relevant issue for VS 2017 detection: rust-lang/rust#38584 |
|
@Diggsey Have more guide text is better than let the users sink themselves in unexpected issues and try to search for the solutions (It costs me a full afternoon to experiment with different installation settings). I had a great getting started with Golang in the past, I only need to run the official go1.8.windows-amd64.msi and it does the all the tedious tasks for me without relying on Visual Studio/C++ toolchain. Each time, I want to update my Go or Node version, just download the official installer and run... DONE. I don't have enough background in Computer Science, programming language & compiler design. But I think a modern system programming language like Rust should not rely on C++ build tools to compile & run HelloWorld program. I hope Rust could be that awesome and more beginner friendly. |
|
@redstrike I agree we should do more documentation-wise. I'm afraid what you're suggesting isn't really feasible for rust. Go avoids a dependency on a VC++ toolchain by implementing their own custom linker, which only works for go, and it comes with significant downsides. For example, as soon as you depend on a C library, you're back to needing a proper VC++ linker again. NodeJS isn't really comparable because javascript isn't a compiled language. However, if you use any npm libraries that have native dependencies, you'll again need the VC++ build tools. Basically. In the future, we may be able to automatically start the VC++ build tools installation if the user requests it, when rustup is initially installed, and I think that's as good as it's likely to get honestly. |
|
There seem to be several interrelated bugs here, and I'm not clear on them. There's the bug to teach rustc how to find the VC 2017 linker. That is not this bug. This is a bug about rustup-init not detecting a usable VC 2017 install. I'm not clear on why this is only a crisis now, when the VC 2017 bug in rustc has existed since 2016/12/31. Can anybody explain? (Maybe it only hit stable recently). Since rustc doesn't work correctly with some VC 2017's, doesn't that mean that even if rustup fixes its own detection, that rust will still be broken? Does anybody know what the necessary change to rustup is to make this detection work? How many versions of VS 2017 are there, and which ones work correctly with rustc, which ones don't work correctly with rustc, which ones work with rustup, which don't work with rustup? |
|
Getting Rust to not depend on a C++ toolchain is quite a long way in the future and would involve several things:
|
Because VS 2017 only had its actual stable release in March. Before then it was just previews and release candidates.
Unless you use vcvars to manually configure your environment, yes. Or if rustc delegates responsibility for detecting VC++ to rustup, which would involve the rustup proxies doing the autodetection and setting env vars appropriately before calling the actual binaries.
There is just the one VS 2017, and both rustc and rustup do not autodetect it currently. It can however have multiple VC++ toolsets installed and provides a COM api to select one of those toolsets which I am currently working with. |
|
Thanks @retep998. |
|
This discussion is getting a bit derailed. This is NOT about VS 2017. This is about rustup not detecting VC++ Build Tools (note the title). The VS 2017 thing just shines light on what's happening.
It is not at all obvious from the rustup installation page that you need, say, the Windows SDK. It just says VC++ toolset, which was installed, and present in the programs list, but not picked up by rustup. When you run rustup, it complains about the toolset.
This is true, and that's why I went for the VC++ Build Tools install at first. But it's also a very weird experience when your VC++ 2017 install, which Rust is incapable of detecting, fixes the issue by apparent side effect of installing extra missing components rustup didn't specify were needed (such as the Windows SDK). The problem I reported is with rustup not detecting the VC++ 2015 Build Tools, not VS 2017. It's completely understandable for rustup to not detect VS 2017. But it's a bad user experience when it tells you that VC++ 2015 Tools are OK, you install them, and it literally tells you they're not installed... when they're there... if it wants the SDK, it should say it wants the SDK. I hope that clears my complaint up. |
|
@projektir Ah, I think I see part of the confusion:
No, it says you need either (the VC++ build tools, which includes all three components), or (a full Visual Studio installation with the "C++ tools" option checked). I can see why it would be easy to misread that and believe that the "C++ tools" option applied to the former, but it only applies to the full visual studio option. Note that when you customize the installation and remove those components, you no longer have the VC++ build tools installed. The installer just happens to be modular - if you uncheck every component it will essentially install nothing, there's no "core" selection of required components.
But it is detecting them when they exist, you just don't have the "VC++ 2015 Build Tools" installed if you unchecked those components. Phrasing it as a detection problem is what started the confusion around VS 2017. |
That doesn't seem true according to Microsoft, because there's a minimum install size to the build tools (2 GB), and when I checked my programs list, it listed Microsoft Visual C++ Build Tools as installed. So while this may be true in some sense, it's not any kind of obvious sense. A given person may not be an expert on how rustup uses these tools, or how MS names their components, and shouldn't need to be. It's not infrequent for installers to come with a bunch of extra components a person may choose not to want to install for various reasons. I think a small update to the rustup page to say that you need all modules that come with the MS VC++ installer wouldn't hurt, and I'm perfectly willing to create a PR for that as long as everyone's OK with that. I would have made a PR straight away if I didn't think originally that this was a problem with rustup's detection, rather than semantic issues around what "VC++ Build Tools" actually means. |
|
Also, sorry to hammer this point further but I really think usability issues like this are very important to Rust's growth. Consider @redstrike comment here:
So if I'm understanding them correctly (I probably want to test this myself), regardless of which packages you choose, being in CUSTOM mode produces an installation rustup can't detect... that's definitely not something you can expect the average user to realize, I hope we can agree on that? |
|
So basically I need to split out all the VC++ detection logic into a separate crate which can provide diagnostics for why it failed to locate a suitable VC++ installation, including specific errors messages such as for when you have VC++ but not the Windows SDK. Then I need to make sure rustup, gcc, and rustc all get their detection logic from that crate.
I just remembered that this won't work because of cross compilation and build scripts. |
|
Let's reduce the scope from VS 2017 to this issue. In confusing mode yesterday, I may mismatch linker issue tests with rustup's recognization tests. So, I decided to reinstall VC++ 2015 Build Tools again to give you more information.
rustup can recognize VC++ build tools in custom mode with Windows 8.1 SDK or Windows 10 SDK.Windows 10 SDK is bigger but requires fewer support packages than Windows 8.1 (Ex: VC++ 2013 Redist x86/x64).
|
|
@redstrike So that confirms that there's nothing weird going on, and you just have to remember to select some Windows SDK version when installing the VC++ build tools. The initial fix for this is to expand the diagnostics and documentation to clarify that not only do you need the VC++ build tools, but you need to make sure you also get the Windows SDK with it. Later on we can then upgrade rustup to detect scenarios where VC++ was installed without the Windows SDK and emit a diagnostic telling the user of their mistake and how to fix it. |
|
@retep998 I have a concern about the linker. I could workaround this recognization issue with Default installation mode yesterday, but then I stuck at linker issue.
Installing Visual Studio helped me solve this problem by accident. At the moment, although I removed all VS components, I cannot reproduce the above linker problem anymore, but it may haunt other users in the future. This means just install VC++ 2015 Build Tools is not enough. |
|
@redstrike Looks like you had a broken installation of the Windows 8.1 SDK. As you can see it is passing it via |
In a typical scenario, a beginner's Windows 10 machine usually doesn't have any installed Windows SDK. By default, Windows 8.1 SDK will be installed by VC++ 2015 Build Tools installer instead of Windows 10 SDK. So, if rustc could do sanity checks for Windows 8.1 SDK, it will be better than not. Helpful error messages with some troubleshoot tips are nice to have. By the way, I'm glad to know these kind of issues are still in your control 👍 |
|
This thread is long. But the most important question for us stuck on limbo in windows is: Is there any temporary "recommended" workaround ATM? Maybe post a Q/A on SO? Perhaps add some notes on rustup.rs website? Please. Just anything to get us going with msvc toolchain. |
|
@kosinix Just install the VC++ build tools with default options. Most of us on this thread are using windows with the MSVC toolchain, there's no real issue beyond better explaining what the dependencies are. |
|
@Diggsey I did. Im in similar situation with @redstrike. Windows 10 + vs studio 2017. As a last ditch effort, I uninstalled vs studio 2017 completely (which I tried to avoid since I spent a few days downloading it - third world country internet), uninstalled rustup, and installed vc build tools 2013. Didn't work. Iinstalled vc build tools 2015. Still getting this:
Before this, I had no problems with windows 8.1 + rustup. It seems to be a win10 + vstudio 2017 issue. |
|
@kosinix This is not the issue for VS 2017 detection, please go here for that: rust-lang/rust#38584 |
|
Re: your issue with 2015 build tools, I haven't seen that issue before (assuming you installed with the default installation options), so I'm afraid I can't offer a workaround, but my best guess is that some remnant of the VS 2017 install is lingering around, confusing rustup. @retep998 Does that seem likely? Does everything work if you choose to continue? |
|
@Diggsey unfortunately no. :-( |
|
Thanks @levinem |
|
I've started a fix to gcc-rs: https://github.com/brson/gcc-rs/tree/vs2017 |
|
You're welcome @brson |
This teaches gcc-rs to find tools installed by MSVC 2017. It's not obvious to what extend the new COM interfaces are expected to be use. This patch only uses it to find the product installation directory, then infers everything else. A lot of COM scaffolding to do very little. The toolchains seem to have a different directory structure in this release to better support cross-compilation. It looks to me like all the lib/include logic is pretty much the same as it always has been. This is tested to fix the rustup installation logic, and to fix rustc in basic use cases on x86_64. cc rust-lang#143 cc rust-lang/rustup#1003 cc rust-lang/rust#38584
This teaches gcc-rs to find tools installed by MSVC 2017. It's not obvious to what extend the new COM interfaces are expected to be use. This patch only uses it to find the product installation directory, then infers everything else. A lot of COM scaffolding to do very little. The toolchains seem to have a different directory structure in this release to better support cross-compilation. It looks to me like all the lib/include logic is pretty much the same as it always has been. This is tested to fix the rustup installation logic, and to fix rustc in basic use cases on x86_64. cc rust-lang#143 cc rust-lang/rustup#1003 cc rust-lang/rust#38584
This teaches gcc-rs to find tools installed by MSVC 2017. It's not obvious to what extend the new COM interfaces are expected to be use. This patch only uses it to find the product installation directory, then infers everything else. A lot of COM scaffolding to do very little. The toolchains seem to have a different directory structure in this release to better support cross-compilation. It looks to me like all the lib/include logic is pretty much the same as it always has been. This is tested to fix the rustup installation logic, and to fix rustc in basic use cases on x86_64. cc rust-lang#143 cc rust-lang/rustup#1003 cc rust-lang/rust#38584 cc alexcrichton/curl-rust#161
This teaches gcc-rs to find tools installed by MSVC 2017. It's not obvious to what extent the new COM interfaces are expected to be used. This patch only uses it to find the product installation directory, then infers everything else. A lot of COM scaffolding to do very little. The toolchains seem to have a different directory structure in this release to better support cross-compilation. It looks to me like all the lib/include logic is pretty much the same as it always has been. This is tested to fix the rustup installation logic, and to fix rustc in basic use cases on x86_64. cc rust-lang#143 cc rust-lang/rustup#1003 cc rust-lang/rust#38584 cc alexcrichton/curl-rust#161
This teaches gcc-rs to find tools installed by MSVC 2017. It's not obvious to what extent the new COM interfaces are expected to be used. This patch only uses it to find the product installation directory, then infers everything else. A lot of COM scaffolding to do very little. The toolchains seem to have a different directory structure in this release to better support cross-compilation. It looks to me like all the lib/include logic is pretty much the same as it always has been. This is tested to fix the rustup installation logic, and to fix rustc in basic use cases on x86_64. cc rust-lang#143 cc rust-lang/rustup#1003 cc rust-lang/rust#38584 cc alexcrichton/curl-rust#161
Detect MSVC 2017. Closes #1003 Rust itself won't actually work until it is also updated. This just lets rustup install without a warning.
Detect MSVC 2017. Closes #1003 Rust itself won't actually work until it is also updated. This just lets rustup install without a warning.
Detect MSVC 2017. Closes #1003 Rust itself won't actually work until it is also updated. This just lets rustup install without a warning.
This teaches gcc-rs to find tools installed by MSVC 2017. It's not obvious to what extent the new COM interfaces are expected to be used. This patch only uses it to find the product installation directory, then infers everything else. A lot of COM scaffolding to do very little. The toolchains seem to have a different directory structure in this release to better support cross-compilation. It looks to me like all the lib/include logic is pretty much the same as it always has been. This is tested to fix the rustup installation logic, and to fix rustc in basic use cases on x86_64. cc rust-lang#143 cc rust-lang/rustup#1003 cc rust-lang/rust#38584 cc alexcrichton/curl-rust#161
|
Why is Rust still relying on this slow MS crap? It's been years... |
|
@kragil I understand you are frustrated, though its not clear what has caused that, but please be kind or at least courteous in this bugtracker: we follow, and require everyone participating here to follow, the rust code of conduct: https://www.rust-lang.org/policies/code-of-conduct - in particular calling the MS toolchains "slow crap" is rude an unnecessary. That said, your question would be best answered in the rust forums I think; rustup focuses on installing rust, not on defining what rust does or does not require. |
|
I'm trying to install Rust. I have MSVS 2022 installed, tried various versions of MSVC and Windows 10 SDK. Rustup still rejects me with this infamous window. Any suggestions in 2022 please? |
Previously, rustc and related tools worked fine for me, but I had VS itself installed with the C++ tools. I've just reinstalled Windows 10. I've installed Visual C++ Build Tools from the landinghub link, no SDK,, but when I run rustup-init.exe, it still tells me that it's missing. There's nothing else Rust or Visual Studio related on my machine.
I ran the installer again, but it has nothing to offer besides installing SDK's that I don't need.
I've installed updates and restarted my computer, but that didn't help.
I've added the Microsoft Visual C++ Build Tools folder to PATH, that didn't help, either.
Either rustup truly needs more than just the Build Tools themselves, or it's not doing a very good job of detecting it.
The text was updated successfully, but these errors were encountered: