visual studio 2010 express + win sdk = cannot open input file 'kernel32.lib'

Question

I used to compile for x64 using VS2008 express and win SDK. Recently rebuilt my machine (upgraded to 64bit Windows 7) and got latest express installed. Followed the same procedure to allow x64 targets and my sources don't link any more. no matter what I do I always get:

LINK : fatal error LNK1181: cannot open input file 'kernel32.lib'

funny enough 32bit compilation works fine.

Is this some well know problem? Google didn't give me any clues how to tackle it just a couple of mentions of the same problem but no solutions.

Is it possible to use VS 2010 with win 7 SDK to target 64bit?

thanks Pawel

Boxfish

Answer 1

the solution was dead easy at the end. The trick is to point VS to win SDK that for some reason was incorrect in my case. Project Properties -> VC++ Directories -> Library Directories should point to C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\x64

Boxfish

You are my favorite person in the world right now. :-) – Bastia

Answer 2

Something else I found, also dead easy, is to go to Project Properties->General and set Platform Toolset to Windows7.1SDK. Wonder why this works...

Litotes

I don't see "Platform Toolset" under General - I only see "Output Directory", "Intermediate Directory", "Configuration Type", "Common Language Runtime Support", and "Build Log File". However pawel's answer works for me. – Mirianmirielle

This answer worked for me when upgrading from VS 2013 community to 2017 Community – Snapper

Answer 3

I've had the same problem and the answers here helped me, but I had to do more things.

Something had corrupted my Windows SDK installation, so I was missing all .lib files that go into C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\ (the x64 folder inside was ok). So I followed what's been said here and reinstalled it. Than I could set Platform Toolset to Windows7.1SDK (in both VS2010 and VS2013).

This works because the Platform Toolset changes the $(WindowsSdkDir) path within Visual Studio (those paths saved are in the system registry), which were broken if Kernel32.lib isn't found.

Waechter

Thanks for the edit @Matthieu. Something else I've tried was to install VS2010 Express, so that I could set Platform Toolset to VS100 instead of Windows7.1SDK - that also worked for me. I did that because other people in my team were using this setting, and we wanted to avoid conflicts later. – Waechter

Answer 4

If none of the above solutions worked. Stop and do a sanity check. I got burned using the wrong -G config string and it gave me this misleading error.

First, run from the VS Command Prompt not the regular command prompt. You can find it in Start Menu -> Visual Studio 2015 -> MSBuild Command Prompt for VS2015

This sets up all the correct paths to VS tools, etc.

Now see what generators are available from cmake...

cmake -help

...<snip>... The following generators are available on this platform: Visual Studio 15 [arch] = Generates Visual Studio 15 project files. Optional [arch] can be "Win64" or "ARM". Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files. Optional [arch] can be "Win64" or "ARM". Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files. Optional [arch] can be "Win64" or "ARM". Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files. Optional [arch] can be "Win64" or "ARM". Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files. Optional [arch] can be "Win64" or "IA64". ...

Then chose the appropriate string with the arch added.

mkdir _build cd _build cmake .. -G "Visual Studio 15 Win64"

Running cmake in a subdirectory makes it easier to do a 'clean' since you can just delete everything in that directory.

I upgraded to Visual Studio 15 but wasn't paying attention and was trying to generate for 2012.

Grope

Answer 5

FWIW, I had the same problem with Visual Studio 2013 when the entire v8.1 SDK install (files + reg keys) went AWOL, probably caused by the installation of Emborlandero RAD Studio.

Setting the WindowsSdkDir environment variable had no effect since both Studio itself (devenv.exe, environment inspected via Process Explorer) and a batch file called from a batch file called from vcvarsall.bat effectively erased that variable because they couldn't find the v8.1 SDK.

Visual Studio doesn't allow machine-specific directories to be configured in a machine-wide way (the suggestion to put this machine dependency into each and every project file is ludicrous beyond belief) and re-installing the v8.1 SDK was not possible in a timely fashion. A quick fix to get Studio working again in the meantime was to add the string value InstallationFolder under

Software/Microsoft/Microsoft SDKs/Windows/v8.1/

with the same contents as its v8.0 cousin. This was under HKLM/Wow6432Node but plain HKLM or HKCU should work as well.

That got Studio working again immediately, without even a restart.

Hine