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

Windows 10 SDK detection broken with new SDK #30229

Closed
retep998 opened this issue Dec 6, 2015 · 6 comments · Fixed by #30233
Closed

Windows 10 SDK detection broken with new SDK #30229

retep998 opened this issue Dec 6, 2015 · 6 comments · Fixed by #30233
Labels
O-windows Operating system: Windows O-windows-msvc Toolchain: MSVC, Operating system: Windows

Comments

@retep998
Copy link
Member

retep998 commented Dec 6, 2015

The new Windows 10 SDK changed some registry values slightly which broke the current Windows 10 SDK detection code.

This results in the linker error note: LINK : fatal error LNK1181: cannot open input file 'ws2_32.lib'

I am working on a PR to fix this completely overhaul the code for the better.

In the meantime you can work around this issue by manually invoking vcvars as done here.

@retep998
Copy link
Member Author

Alas, because this isn't a regression, even when my PR does land, this issue will continue to plague people until it proliferates into stable.

bors added a commit that referenced this issue Dec 15, 2015
…alexcrichton

What I've done here is try to make the code match what vcvars does much more closely. It now chooses which SDK to find based on the version of MSVC that it found. It also bases the decision of whether to find all the things on whether `VCINSTALLDIR` has been set, which is more likely to have only been set by an invocation of vcvars, unlike previously where it would do some things only if `LIB` wasn't set even though there was a valid use case for libraries to add themselves to `LIB` without having invoked vcvars.

There are still some debug `println!`s so people can test the PR and make sure it works correctly on various setups.

It supports VS 2015, 2013, and 2012. People who want to use versions of VS older (or newer) than that will have to manually invoke the appropriate vcvars bat file to set the proper environment variables themselves.

Do not merge yet.

Fixes #30229
@mhristache
Copy link

Can this be back ported to beta pls? ping @alexcrichton

@retep998
Copy link
Member Author

retep998 commented Jan 7, 2016

That would involve back porting #30233 and #30516

@brson brson added beta-nominated Nominated for backporting to the compiler in the beta channel. I-nominated and removed beta-nominated Nominated for backporting to the compiler in the beta channel. I-nominated labels Jan 7, 2016
brson pushed a commit to brson/rust that referenced this issue Jan 12, 2016
@steveklabnik
Copy link
Member

I ran into this today with someone, but the file was userenv.lib. Rust 1.21.0. Haven't been able to debug it.

@retep998
Copy link
Member Author

@steveklabnik In general when someone gets an error where the linker can't find a system library (rather than being unable to find the linker), this is typically because they have an incomplete Windows SDK. To debug this, you'd need to know which paths the linker is searching in (via the /LIBPATH arguments which you can view when the linker command line is printed out because linking fail). Find the directory which corresponds to the Windows SDK (such as C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\um\x64) and check whether that library actually exists there. If not, that version of the Windows SDK may need to be repaired or reinstalled.

@steveklabnik
Copy link
Member

Thanks!

In the end, my student uninstalled and reinstalled both the Windows stuff and Rust stuff, and it magically worked, so I bet that was it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-windows Operating system: Windows O-windows-msvc Toolchain: MSVC, Operating system: Windows
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants