Skip to content

/rust

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

Comments

Assignees
No one assigned
Labels
O-windows O-windows-msvc
Projects
None yet
Milestone
No milestone
6 participants
@retep998 @mhristache @steveklabnik @brson @cmr @apasel422
@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 retep998 referenced this issue Dec 6, 2015

Closed

windows appveyor build failing #43

retep998 added a commit to retep998/rust that referenced this issue Dec 6, 2015

@retep998
Overhaul MSVC linker and Windows SDK detection code 
Fixes rust-lang#30229

Signed-off-by: Peter Atashian <retep998@gmail.com>
00b9542

retep998 added a commit to retep998/rust that referenced this issue Dec 6, 2015

@retep998
Overhaul MSVC linker and Windows SDK detection code 
Fixes rust-lang#30229

Signed-off-by: Peter Atashian <retep998@gmail.com>
bf1cb1b

This was referenced Dec 6, 2015

Merged
Closed

@sfackler sfackler referenced this issue Dec 13, 2015

Closed

64 bit MSVC nightlies seem to have troubles linking #30358

@apasel422 apasel422 added the O-windows label Dec 14, 2015

@cmr cmr added the O-windows-msvc label Dec 14, 2015

@mbrt mbrt referenced this issue Dec 14, 2015

Closed

Fix appveyor builds #43

@tomaka tomaka referenced this issue Dec 14, 2015

Merged

[WIP] Wayland backend rewrite #674

retep998 added a commit to retep998/rust that referenced this issue Dec 14, 2015

@retep998
Overhaul MSVC linker and Windows SDK detection code 
Fixes rust-lang#30229

Signed-off-by: Peter Atashian <retep998@gmail.com>
915cb37

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

@bors
Auto merge of #30233 - retep998:where-in-the-world-is-windows-sdk, r=… 
…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
ecae5f2
@retep998

This comment has been minimized.

Sign in to view
Copy link
Member Author

retep998 commented Dec 15, 2015

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

@bors
Auto merge of #30233 - retep998:where-in-the-world-is-windows-sdk, r=… 
…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
98ef4cc

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

@bors
Auto merge of #30233 - retep998:where-in-the-world-is-windows-sdk, r=… 
…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
9e63cec

@bors bors closed this in #30233 Dec 15, 2015

ubsan added a commit to ubsan/rust that referenced this issue Dec 22, 2015

@retep998 @ubsan
Overhaul MSVC linker and Windows SDK detection code 
Fixes rust-lang#30229

Signed-off-by: Peter Atashian <retep998@gmail.com>
0dec6bb

@micbou micbou referenced this issue Jan 5, 2016

Closed

Use MSVC version of the Rust compiler on AppVeyor #293

@mhristache

This comment has been minimized.

Sign in to view
Copy link

mhristache commented Jan 7, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Member Author

retep998 commented Jan 7, 2016

That would involve back porting #30233 and #30516

@brson brson added beta-nominated I-nominated T-tools and removed beta-nominated I-nominated T-tools labels Jan 7, 2016

@brson brson referenced this issue Jan 7, 2016

Merged

Fix Universal CRT detection on weird setups #30516

brson added a commit to brson/rust that referenced this issue Jan 12, 2016

@retep998 @brson
Overhaul MSVC linker and Windows SDK detection code 
Fixes rust-lang#30229

Signed-off-by: Peter Atashian <retep998@gmail.com>
93b06f4

@briansmith briansmith referenced this issue Jan 12, 2016

Closed

cargo build on Windows doesn't work out of the box #12

@steveklabnik

This comment has been minimized.

Sign in to view
Copy link
Member

steveklabnik commented Oct 26, 2017

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

This comment has been minimized.

Sign in to view
Copy link
Member Author

retep998 commented Oct 26, 2017

@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

This comment has been minimized.

Sign in to view
Copy link
Member

steveklabnik commented Oct 30, 2017

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.

@kennytm kennytm referenced this issue Nov 13, 2017

Closed

error: linking with `link.exe` failed: exit code: 3221225781 #42744

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.