Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not work with latest Windows 10 SDK #5

Closed
GabrielMajeri opened this issue Jun 21, 2017 · 8 comments
Closed

Does not work with latest Windows 10 SDK #5

GabrielMajeri opened this issue Jun 21, 2017 · 8 comments

Comments

@GabrielMajeri
Copy link
Contributor

GabrielMajeri commented Jun 21, 2017

Hello, I tried to install the cargo-update crate and ran into an issue. I believe it is caused by this crate, and the way it handles finding RC.exe.

--- stderr
thread 'main' panicked at 'Are you sure you have RC.EXE in your $PATH?:
Error { repr: Os { code: 2, message: "The system cannot find the file specified." } }', 
src\libcore\result.rs:860

The reason I don't have RC.exe in my $PATH is because since VS 2017, you can have multiple installed versions of VS 2017 on the same machine, and they are not added to the path anymore.

Now, I do have VS 2017 installed, and the C++ build tools, and Rust nightly does work and uses the VS 2017 linker. Is there a way for this crate to support VS 2017 too?

The solution for Rust was to just update the gcc crate, which supports VS 2017 out of the box.

A temporary solution I found is: open the "x64 Native Tools Command Prompt for VS 2017", and run cargo install from there. But, again, it would be great if this crate worked with VS 2017 without special preparation.


Some more information:
Finding installed Visual C++ tools for Visual Studio 2017

@nabijaczleweli
Copy link
Owner

I look for RC.EXE in various places here; it's probably possible to look for the 2017 version there, too. I'll see to it.

@nabijaczleweli
Copy link
Owner

After trying to read the shitty vswhere source (which I assume I can't just use because it's not a native VS binary) and attempting to comb through gcc-rs' -- I don't know how either of them do it. I'm guessing it's somewhere down the registry rabbit-hole, but where - I know not. Pointers would be appreciated.

@GabrielMajeri
Copy link
Contributor Author

GabrielMajeri commented Jun 22, 2017

I checked and gcc-rs only check in the Visual Studio folder. It seems rc.exe only is included in the SDK, not VS. I do have Windows 10 SDK installed - I'll see why embed-resource does not find it.

@GabrielMajeri
Copy link
Contributor Author

GabrielMajeri commented Jun 22, 2017

I've found the problem - embed-resource probes the <Windows SDK>/bin/x86 and /x64 folders.

But on the newest Windows SDK, the executable has been moved to /bin/10.0.15063.0/x64/.


It looks like the Windows Kits/Installed Roots now has subkeys, which are the version numbers (e.g. 10.0.15063.0). Perhaps this crate should parse these subkeys, pick one and use that version of rc.exe?

@GabrielMajeri GabrielMajeri changed the title Support Visual Studio 2017 Does not work with latest Windows 10 SDK Jun 22, 2017
nabijaczleweli added a commit that referenced this issue Jun 22, 2017
@nabijaczleweli
Copy link
Owner

I'd be grateful if you tested the referenced commit; I tried to do my best but there's only so far I can go without an actual test env for this.

@GabrielMajeri
Copy link
Contributor Author

GabrielMajeri commented Jun 23, 2017

It worked! Thanks. Now all that's left is for cargo-update and possibly other crates to be updated to use the commit.

@nabijaczleweli
Copy link
Owner

Does it really work? I'm really surprised. I'll release with patch bump so all crates that depend on this one get the update automatically. Thanks for the help!

@nabijaczleweli
Copy link
Owner

Released in v1.1.3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants