CMake cannot open "ucrtd.lib"

Question

My problem is similar to this one: Problems generating solution for VS 2017 with CMake, but the solution doesn't work for me.

When run cmake in Developer Command Prompt for VS 2017, I got the error (from CMakeError.log):

LINK : fatal error LNK1104: Cannot open file "ucrtd.lib" [E:\Projects\My Project\VS\CMakeFiles\3.14.4\CompilerIdC\CompilerIdC.vcxproj]

But the file ucrtd.lib is located in the Windows Kits folder.

echo %LIB%

D:\Program Files (x86)\Microsoft Visual Studio 2017 Community\VC\Tools\MSVC\14.16.27023\lib\x86;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x86;C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\ucrt\x86;C:\Program Files(x86)\Windows Kits\10\lib\10.0.17763.0\um\x86;

dir "C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\ucrt\x86\" /w /b

libucrt.lib
libucrtd.lib
ucrt.lib
ucrtd.lib

And I also try to manually run the build command listed in the CMakeError.log, it succeeds, no error.

CL.exe /c /nologo /W0 /WX- /diagnostics:classic /Od /Oy- /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\" /Fd"Debug\vc141.pdb" /Gd /TC /analyze- /FC /errorReport:queue CMakeCCompilerId.c

link.exe /ERRORREPORT:QUEUE /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:".\CompilerIdC.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdC.lib" /MACHINE:X86 /SAFESEH Debug\CMakeCCompilerId.obj

So it seems like cmake didn't recognize the environment variables, or did I miss some important steps?

cmake version is 3.14.4
visual studio version is 15.9.7

Answer 1

tl;dr:

Make sure HKLM\Software\Microsoft\Windows Kits\Installed Roots@KitsRoot10 is set to:

C:\Program Files (x86)\Windows Kits\10\

and NOT:

C:\Program Files\Windows Kits\10\

Full Explanation

On the LNK1104 error page, there's a relevant section titled, "Updated Windows SDK libraries", that reads:

This error can occur when the Visual Studio path to the Windows SDK is out of date. It may happen if you install a newer Windows SDK independently of the Visual Studio installer. To fix it in the IDE, update the paths specified in the VC++ Directories property page. Set the version in the path to match the new SDK. If you use the Developer Command Prompt, update the batch file that initializes the environment variables with the new SDK paths. This problem can be avoided by using the Visual Studio installer to install updated SDKs.

Given this, the reasonable thing to do would seem to be to verify that the "Macro" pointing to the path containing the ucrt library files is in use.

However, this may not be enough. That Macro may be wrong.

This message from a Microsoft engineer says that some older Windows Kits improperly set the path to the ucrt. In these kits, they use the 64-bit program files path ("Program Files") instead of the 32-bit path ("Program Files (x86)"). However, during installation, if the path is already set, then it will not be updated by a subsequent Windows SDK installer.

So it's possible that your system will have the environment variable defined to the wrong value, resulting in Visual Studio failing to find the relevant library.

In that case, the Microsoft engineer's recommendation was to either update the offending registry value, or delete it then reinstall the Windows SDK.

Hey Alexander,

I've spoken to the Windows SDK team about this. In general, kit installers are not supposed to set 'HKLM\Software\Microsoft\Windows Kits\Installed Roots@KitsRoot10' to C:\Program Files\Windows Kits\10, it is always supposed to point to C:\Program Files (x86)\Windows Kits\10. However, there are Kits out there that make this mistake, and the registry key is never updated if it already exists prior to any kit installation. I believe whichever windows kit you've installed on that system first had this issue.

That said, these issues will never go away entirely since there will always be kits and machines floating around with this issue. I've updated ucrt.props to be more defensive about this by checking the Wow6432Node version first (which has not had this issue historically), and only if that isn't present to fall back to the usual registry key.

This fix will be present in the next released Windows 10 SDK. In the meantime, I recommend either deleting that reg key and reinstalling the Windows 10 SDK, or simply directly modifying HKLM\Software\Microsoft\Windows Kits\Installed Roots@KitsRoot10 to point to C:\Program Files (x86)\Windows Kits\10 (the same effects of the deleting the reg key and reinstalling, but less error prone).

Hope this helps!

Steve Wishnousky Senior Software Engineer - Visual C++ Libraries [email protected]

(quoted here because of concerns about the long-term availability of the message at the link)

Answer 2

As described here, if you're on VS2022 and your installed Windows SDK is version 10.0.19041.0 (which is what installs with VS2022 as the default as of this writing), then you may have run into this.

The solution in that case is to uninstall that SDK version and install a different one.

Answer 3

As mentioned in this CMake forum, it may be necessary to explicitly tell CMake which specific Windows version you have installed. Considering you have version 10.0.17763.0 installed, including the following definition will direct CMake to that version:

cmake -DCMAKE_SYSTEM_VERSION=10.0.17763.0

Here are the docs for CMAKE_SYSTEM_VERSION.