microsoft/openssl

Errors while compiling with RS1 (10.0.14393.0) Windows SDK

alanch-ms opened this issue · 3 comments

alanch-ms commented

I ran into 2 issues while compiling with RS1 Windows SDK. It worked fine with TH2 Windows SDK.

  1. The include paths are not set properly. It seems that ms\setVSvars.bat read the registry to find the version of the windows SDK. For TH2, the HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v10.0\ProductVersion is set to "10.0.10586.0". This version matches the directory name for of the include directory, ie. C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um. However, for RS1, it is set to "10.0.14393". Notice the last ".0" is missing. Because of this missing ".0", the include path doesn't match the actual path, C:\Program Files (x86)\Windows Kits\10\Include\10.0.14393.0\um.
  2. I'm getting the following error while linking to libeay32.lib. In o_dir.c, it uses FindFirstFile() for non-uwp configuration. For UWP-configuration, the build process force included the header, winrtdef.h, to #define FindFirstFile() to FindFirstFileEx(). While, this worked in TH2, it's now broken in RS1. In RS1, line 301 of fileapi.h (re-)defined "FindFirstFile" back to "FindFirstFileW". Since "FindFirstFileW" is not a UWP api, we see the link error below.

libeay32.lib(o_dir.obj) : error LNK2019: unresolved external symbol __imp_FindFirstFileW referenced in function OPENSSL_DIR_read

khouzam commented

Thanks for reporting this. I'll take a look with the RS1 SDK.

alanch-ms commented

Actually, regarding point 2, the error was due to version conflict of WinSDK. Openssl-uwp was compile with 10.0.14393.0 (the version in the registry), but the visual studio project consuming the libeay32.lib was targeting 10.0.10586.0 (specified by the VS project file). Hence, FindFirstFileW was not found during the "link" phase.

I guess the correct fix here is to specify which WinSDK version to build openssl against. As far as I can tell, the WinSDK version determine by ms\setVSvars.bat. Is setting the environment variable "_WKITS10VER" before calling ms\setVSvars.bat the correct way of specifying which WinSDK version to use?

(I guess that would be a good workaround for point 1 as well.)

  • 👍2
khouzam commented

Yes, it seems that the logic for the SDK has changed slightly and I'll look to patch the scripts.

  • 👍1