The Shibboleth V1 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only.

OpenSSLNotes

Owned by Scott Cantor
Last updated: Sept 03, 2007Version comment
2 min read

Building OpenSSL on most Unix platforms is fairly straightforward. Just remember to enable the "threads" and "shared" options.

On Windows, the docs can be a little sketchy at times, and the default build is essentially broken. It doesn't supply a proper debug build makefile, it doesn't name its libraries so as to avoid version conflicts, and doesn't support any of the native Windows assembly mechanisms for avoiding conflicts. Given that, a compromise is to modify the default makefiles during the build set up process to create versioned library names to avoid conflicts.

My system includes the MASM assembler and ActiveState Perl, by the way. The directions below are for the latest release (0.9.8c at time of writing). A given generation of lettered versions should be able to share a set of filenames so that you can drop in patched versions at runtime.

First I configure the package from source as follows (latest version at time of topic creation is shown). These steps generate starting makefiles and DEF files that are customized later.

C:> cd \openssl-0.9.8c
perl Configure VC-NT
ms\do_masm.bat
perl util\mk1mf.pl dll VC-NT 1>ms\ntdll.mak
perl util\mk1mf.pl debug dll VC-NT 1>ms\ntdlldebug.mak
copy ms\libeay32.def ms\libeay32d.def
copy ms\ssleay32.def ms\ssleay32d.def

Now edit the DEF files to adjust the module names embedded inside the libraries we're building. The module name is specified near the top in the LIBRARY command. Modify as follows:

  • ms\libeay32.def: LIBEAY32_0_9_8
  • ms\libeay32d.def: LIBEAY32_0_9_8D
  • ms\ssleay32.def: SSLEAY32_0_9_8
  • ms\ssleay32d.def: SSLEAY32_0_9_8D

Now modify the default makefiles (ms/ntdll.mak and ms/ntdlldebug.mak) to change output information and adjust some settings. If you're using VS 2005, you have to remove the /WX option from CFLAGS because some warnings are being generated by the 8.0 compiler. You'll also need to add the unicows.lib library to the library link commands.

In ms/ntdll.mak:

  • Remove /WX from CLAGS (VS 2005 only)
  • Edit the O_SSL/O_CRYPTO and L_SSL/L_CRYPTO macros around line 78 or so to reflect the corrected filenames:
    • O_SSL= $(LIB_D)\$(SSL)_0_9_8.dll
    • O_CRYPTO= $(LIB_D)\$(CRYPTO)_0_9_8.dll
    • L_SSL= $(LIB_D)\$(SSL).lib
    • L_CRYPTO= $(LIB_D)\$(CRYPTO).lib
  • Near the bottom of the file, edit the link commands to set the import library filenames by adding /implib:$(L_CRYPTO) and /implib:$(L_SSL) to the respective links.

In ms/ntdlldebug.mak:

  • Remove /WX from CLAGS (VS 2005 only)
  • Edit the O_SSL/O_CRYPTO and L_SSL/L_CRYPTO macros around line 78 or so to reflect the corrected filenames:
    • O_SSL= $(LIB_D)\$(SSL)_0_9_8D.dll
    • O_CRYPTO= $(LIB_D)\$(CRYPTO)_0_9_8D.dll
    • L_SSL= $(LIB_D)\$(SSL)D.lib
    • L_CRYPTO= $(LIB_D)\$(CRYPTO)D.lib
  • Near the bottom of the file, edit the link commands that reference the DEF files to refer to the correct debug filenames (LIBEAY32D.DEF and SSLEAY32D.DEF) and set the import library filenames by adding /implib:$(L_CRYPTO) and /implib:$(L_SSL) to the respective links.

With those changes made you can run nmake.exe against those makefiles to generate debug and release builds with properly isolated filenames. You'll get an openssl.exe command line linked to them as well.

The other big advantage is that you can stick the library path to both out32dll and out32dll.dbg directly in your Visual Studio global library directory list since the link library names are now distinct.