search

microsoft / openssl

A cross-platform cryptographic library
133 stars 57 forks source link

This is how building for VS2017 works for me... #47

Open skuskusku opened 6 years ago

skuskusku commented 6 years ago

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):

  1. 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.
  2. 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

  1. 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

  1. Execute the following in this command prompt:

ms\do_vsprojects15.bat

This requires that perl can be located via the PATH environment variable

  1. 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

skuskusku commented 6 years ago

I just saw that my previous text looks a bit garbled, so this is an attempt to upload my version of setVSvars.bat as a text file here, dunno if this works:

setVSvars.bat.txt

khouzam commented 6 years ago

Thanks @skuskusku. I've cleaned up the build scripts, added support for the 16299 SDK, fixed a couple of issues and pushed out an update. Please try it and I'll merge it into the WinRT branch.

skuskusku commented 6 years ago

Hello Mr, Khouzam,

It builds for all platforms with _WKITS10VER=10.0.15063 successfully and all tests are passed successfully as well. I will try in the next few days with 10.0.16299. Is this branch expected to work with the 10240 SDK as well or isn't it worth a try at all?

As a side note: One thing I noticed is that when building from the IDE, the library project files always seem to want recompilation after a successful build. So when attempting to debug one of the test apps, VS will always prompt you to build the libraries again before debugging. This, of course is only a minor annoyance, and I don't know if this ever worked. But in case you can identify this as a regression, maybe you know what needs to be done from memory.

Thanks again,

-- S

skuskusku commented 6 years ago

Hello Mr. Khouzam,

I can confirm that things work as well with the 16299 SDK, all configurations build and test successfully. I tried with the 10240 SDK as well but this failed with

1>.\ms\winrt.cpp : fatal error C1107: could not find assembly 'windows.foundation.foundationcontract.winmd': please specify the assembly search path using /AI or by setting the LIBPATH environment variable

With settings for the 10240 SDK, the LIBPATH environment variable is just not set. So if this SDK is intended to be supported, something has still to be done here.

Let me know if this is enough information for merging into the main trunk.

Greetings,

-- Stefan