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.

Sign up for GitHub

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

Jump to bottom

Fails to build with VC++ build tools #161

Closed
Diggsey opened this issue Apr 30, 2017 · 7 comments
Closed

Fails to build with VC++ build tools #161

Diggsey opened this issue Apr 30, 2017 · 7 comments

Comments

@Diggsey
Copy link

Diggsey commented Apr 30, 2017 •
edited
Loading

Fails to find rc, on this line:

https://github.com/alexcrichton/curl/blob/651be36a7459015d601c22dc36161c9db60c7a1c/winbuild/MakefileBuild.vc#L497

Presumably with a full MSVC install, nmake ensures that rc is on the PATH.
@alexcrichton
Copy link
Owner

Do you have more info about this? Do the vc++ build tools not include rc? Are they in a special location? Are you using 2017? 2015?

@Diggsey
Copy link
Author

Diggsey commented May 6, 2017

I have the VC++ 2015 build tools installed, in addition to Visual Studio 2017, everything with default settings.

VC++ build tools includes rc, but it's part of the windows SDK rather than part of the compiler, so it's not in the same directory as the other compiler tools.

As a work-around, I was able to copy rc.exe and the DLL it depends on, into the compiler bins directory.

@alexcrichton
Copy link
Owner

This crate currently relies on gcc-rs to do detection of these tools, so is there something else that needs to be added to PATH by gcc-rs? What is the special dir that rc is located in? For example is there another path that should be pushed here?

@Diggsey
Copy link
Author

Diggsey commented May 8, 2017

It looks like the issue is here: https://github.com/alexcrichton/gcc-rs/blob/88eb0745dd2b4525a8d11961e31c6acd1277a5c3/src/windows_registry.rs#L273

This checks that a given SDK is "complete" by looking for kernel32.lib. My installation has this library, and so it tries to use the windows 10 SDK rather than the windows 8 SDK. However, only the windows 8 SDK includes the required binary rc.exe.

I'm afraid I don't know what the correct checks should look like, to ensure that a given SDK is complete. Maybe @retep998 can help?

@retep998
Copy link

retep998 commented May 8, 2017

What could work as a solution is finding the Windows SDK for bin purposes independently of finding the Windows SDK for library purposes.

@brson
Copy link

brson commented May 24, 2017

I will include a fix for it in my gcc-rs patch for vs2017.

brson added a commit to brson/gcc-rs that referenced this issue May 24, 2017
@brson
Add MSVC 2017 detection
260bf1d 
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
@brson brson mentioned this issue May 24, 2017
Merged
brson added a commit to brson/gcc-rs that referenced this issue May 24, 2017
@brson
Add MSVC 2017 detection
b161779 
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
brson added a commit to brson/gcc-rs that referenced this issue May 24, 2017
@brson
Add MSVC 2017 detection
4ea110e 
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
@alexcrichton
Copy link
Owner

In theory closed by rust-lang/cc-rs#160, but if it's still her ejust let me know!

FaultyRAM pushed a commit to FaultyRAM/gcc-rs that referenced this issue Aug 10, 2017
@brson @FaultyRAM
Add MSVC 2017 detection
02df4c4 
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@alexcrichton @brson @Diggsey @retep998