Hello,
first of all thanks to Mr. Khouzam for his work on the UWP build of openssl. I had some problems getting the VS2017 build working so in case others have the same problem, this is what works for me (see my specs below):
- Download the file openssl-OpenSSL_1_0_2_WinRT-stable-vs2017.zip and unpack recursively into a directory such as c:\openssl-OpenSSL_1_0_2_WinRT-stable-vs2017.
- Apply the following patch (which I will try to describe below) to ms\setVSvars.bat (the revisions 9023 and 9031 come from my SVN)
Index: setVSvars.bat
--- setVSvars.bat (revision 9023)
+++ setVSvars.bat (revision 9031)
@@ -29,10 +29,12 @@
call:setVar _VS15VC VisualStudio15VC
if not "%_VS15VC%"=="" (
call "%_VS15VC%\vcvarsall" x86_arm store
-
rem
call:setEnv
goto :eof
)
call:setVar _VS14VC VisualStudio14VC
- rem
call "%_VS14VC%vcvarsall" x86_arm store
call:setEnv
goto :eof
@@ -207,7 +209,7 @@
call:setVar _VS15VC VisualStudio15VC
call:setVar _WKITS10 WindowsKits10.0
call:setVar _WKITS10VER WindowsKits10Version
- set LIBPATH=%LIBPATH%;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.foundationcontract\2.0.0.0;%_WKITS10%references%_WKITS10VER%.0\windows.foundation.foundationcontract\3.0.0.0;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.universalapicontract\2.0.0.0;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.foundationcontract\1.0.0.0;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.universalapicontract\4.0.0.0;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.universalapicontract\3.0.0.0;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.universalapicontract\2.0.0.0;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.universalapicontract\1.0.0.0\
- set LIBPATH=%LIBPATH%;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.foundationcontract\3.0.0.0;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.foundationcontract\2.0.0.0;%_WKITS10%references%_WKITS10VER%.0\windows.foundation.foundationcontract\3.0.0.0;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.universalapicontract\2.0.0.0;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.foundationcontract\1.0.0.0;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.universalapicontract\4.0.0.0;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.universalapicontract\3.0.0.0;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.universalapicontract\2.0.0.0;%_WKITS10%\references%_WKITS10VER%.0\windows.foundation.universalapicontract\1.0.0.0
goto :eof
:end
- Open a command prompt (not a VS2017 developer command prompt, doesn't matter if it is an x64 or x86 command prompt) and type:
set _WKITS10VER=10.0.15063
- Execute the following in this command prompt:
ms\do_vsprojects15.bat
This requires that perl can be located via the PATH environment variable
- Run the following from this command prompt:
vsout\openssl.sln
This will fire up VS2017 (unless the .sln extension is tied to a specific version of VS on your computer)
Now build from within Visual Studio 2017. Remember to always set the _WKITS10VER environment variable to 10.0.15063 before firing up a build next time and invoking visual studio to build again. This is the only SDK version that I have found to be working. With this setup, all three platform builds work for me and the tests in the sample apps all pass successfully.
The changes in my patch with the two rem statements look odd and honestly I have no idea why they make things work for me, but I have observed on three machines with VS2017 only that they make things work. Without the first rem statement, the ARM build fails with
'"\vcvarsall"' is not recognized as an internal or external command,
and without the second one, the x64 build (sic!) fails with the same error. Most probably I have overlooked something stupid and obvious, but things work this way.
The last change to the LIBPATH environment variable is what I found is needed for a successful x64 link stage.
Maybe this helps other people to get things working as well. I would be happy if someone has an idea, why the original setVSvars.bat fails with the errors mentioned above so this kludge of mine with those strategically placed :-) rem statements can be replaced with something more meaningful.
Specs: Tested this on three different development machines with either creator's update or fall creator's update. Neither of them had VS2015 installed, all had VS2017 installed. One of the machines had a previous installation of VS2015 installed but removed, but maybe there are some remnants of the VS2015 installation that I am unaware of.
Stefan