9 December, 2015 (published)
  9 December, 2015 (last modified)

Compiling OpenSSL on Windows (msvc)

  Categories: c++, MS Windows, Qt
  Tags:  , , , ,

visual_studiolpngThe present post is a recipe for building the static and dynamic OpenSSL libraries for all versions of OpenSSL on the Windows platform, viz. msvc32 and msvc64. We are using the Microsoft Visual Studio 2013 C++ compiler. In another posts we treat the mingw (Minimal GNU for Windows) toolchain. Our goal is to have in the end the following libraries (each for 32bit and 64bit that all have 32 in their name even then 64bit versions):

 

static:

libeay32.lib
ssleay32.lib

 

dynamic

libeay32.dll
ssleay32.dll

 

And the import, export, debug files *.exp, *.lib, and*.pdb with "*" equal to "libeay32" or "ssleay32" that are possibly useful when linking dynamically.

Troubleshooting

We start with common errors that are to be avoided.

  • do not use "make clean" to correct for a faulty build. Delete the whole branch and replace by a fresh decompressed OpenSSL tarball.
  • only open terminal windows through the msvc compiler shortcuts and not just a "cmd.exe" terminal.
  • internet fora are full of reports of failed OpenSSL compilations. One such a source of errors is the use of the assembler.  Our recipes work but they do not necessarily produce the smallest and/o the fastest binaries.  We use explicitly use the nasm assembly compiler for 32bit.
  • the OpenSSL tarballs may contain file links that are often corrupted by windows decompress utilities. Note that the final "include/openssl" dir should contain only real header files and not file links.

Quick editing of the PATH environment variable

You will have to run several applications from the command line to compile OpenSSL. For your convenience it is advisable to have the location of these applications in your PATH environment. In earlier days one had to restart Windows to have a change in the SYSTEM environment to become active. This awkward situation has changed now. We use the free gui utility Rapid Environment Editor with which you can edit the SYSTEM and USER environment variables in such a way that these changes become immediately active if you open a *new* instance of explorer or a *new* instance of the MS-DOS terminal window (cmd.exe). Sometimes Windows caches the environment variables in such a way that a new change will not become active. This unwanted situation could occur for instance after installing a new program that adds its own file location to the PATH environment. To force to refresh the cache just edit the PATH variable and save and then undo the previous edit and save again. Now the most actual PATH will be known to all applications that need the environment for their execution.

Requirements

All the following requirements are essential. Do not go to a next requirement if you have not fulfilled the previous requirement.

  1. perl
    You will need the perl program. Open an MS-DOS command window and run

    perl -v

    If you get something like:

    'perl' is not recognized as an internal or external command ...

    you do not have perl installed. We advise to use the free ActiveState perl distribution. Then running the previous command should give something like:

    This is perl 5, version 20, subversion 2 (v5.20.2) built for MSWin32-x64-multi-thread  (with 1 registered patch, see perl -V for more detail) Copyright 1987-2015, Larry Wall Binary build 2002 [299195] provided by ActiveState http://www.ActiveState.com

    You are OK now.

  2. Microsoft Visual Studio c++ compiler
    I assume you have this compiler, msvc from now on, installed (community edition is free). We use the 2013 version. The msvc compiler needs quite a number of environment variables set for it to run properly. For this to work on the command line you will have to open a command line terminal window using the shortcuts that come with the installation of the msvc compiler.
  3. Assembler
    OpenSSL allows for using an assembler to produce speed-optimized binaries. We will use the nasm compiler for 32bit compilation and use the OpenSSL default for 64bit. So download the nasm compiler. Get its binary in your PATH and check with a command window it is visible to all applications. Run

    nasm -v

    with expected response like

    NASM version 2.11.08 compiled on Feb 21 2015
  4. Screen buffer
    The compile procedure will produce hundreds and hundreds of lines in the terminal output. Some of these lines may contain errors or may contain interesting messages. The default screen buffer is set to such a small value that you will lose many of these responses. So any time you open a new terminal check the screen buffer size and set to maximum if this is not already the case.
  5. Windows SDK
    You will need a lot of windows system c++ header files (*.h) to be visible by the compiler. The most convenientt solution is to install the latest version of the Windows 10 SDK. All the necessary headers will then be in the PATH variable.
  6. tar utility
    The OpenSSL source comes as a compressed (gz) archive (tar) which in the Linux world is called a tarball. The OpenSSL archive (may) contain file links. Although Windows supports some form of file links their implementation is not compatible with Linux-type links. As a result the popular zip/unzip Windows utilities can produce incomplete uncompressed archives if there are file links in the archive. For this purpose we strongly advise  to use the GNU "tar" utility to untar the tarball. The tar utility ships with the MSYS distribution. So open an MS-DOS terminal at root and run

    tar --version

    The response should be something like:

    tar (GNU tar) 1.23Copyright (C) 2010 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.Written by John Gilmore and Jay Fenlason.
  7. Decompress source
    Download the required OpenSSL version. Untar the tarball with tar: open a MS-DOS terminal window at the location of the tarball and run

    tar -xvf openssl-ov.tar.gz

    where ov is the OpenSSL version (like 1.0.2e). Neglect the warnings about file links. Check that the tarball is indeed decompressed in its own new directory. We usually copy this source tree to the directories
    openssl-version/msvc32/noshared
    openssl-version/msvc32/shared
    openssl-version/msvc64/noshared
    openssl-version/msvc64/shared

Fast track of our recipes

If you do not want to know about the explanations, just enter in a suitable MS-DOS command window the blue commands to be found below.

Compile msvc32 for static libraries

Open a msvc32 command window (so not just a cmd.exe window) and navigate to the OpenSSL source code. The root dir should contain a file called "Configure". Run

perl Configure VC-WIN32

The final response should be

Configured for VC-WIN32

Run in the same command window

ms\do_nasm

You should get no error responses. Continue in the same window with running

nmake -f ms\nt.mak

You will see the compiling process going on (for about 10 minutes). Your libraries will be at the root of the source tree.

Compile msvc32 for dynamic libraries

Do the same as for static libraries but replace "nt.mak" by "ntdll.mak":

nmake -f ms\ntdll.mak

Compile msvc64 for static libraries

Open a msvc64 command window (so not just a cmd.exe window) and navigate to the OpenSSL source code. The root dir should contain a file called "Configure". Run

perl Configure VC-WIN64A

The final response should be

Configured for VC-WIN64A

Run in the same command window

ms\do_win64a

You should get no error responses. Continue in the same window with running

nmake -f ms\nt.mak

You will see the compiling process going on (for about 10 minutes). Your libraries will be at the root of the source tree.

Compile msvc64 for dynamic libraries

Do the same as for static libraries for msvc64 but replace "nt.mak" by "ntdll.mak":

nmake -f ms\ntdll.mak

You will see the compiling process going on (for about 10 minutes). The generated libraries will be in the out32dll subdirectory.

 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Write a reaction

By submitting a comment here you grant this site a perpetual license to reproduce your words and name/web site in attribution.