Linking OpenSSL on Windows

[Jason Spencer]

I think this thread is not TOO old to use as a place to beg for 
help :)

I've wandered into this nightmare, and I'm hoping someone who's 
been down this road can point the way back to the light.

Summary:  "no OPENSSL_Applink" runtime error when executing D 
openssl application.

I have managed to get basic linking and loading going on the 
sample programs posted here 
(http://forum.dlang.org/thread/yvogpmdjsoproggieabs@forum.dlang.org). 
  I'm using Win32_Openssl_v1.0.0j from Shining Light Productions 
(SLP) at http://slproweb.com/products/Win32OpenSSL.html 
(suggested by klickverbot's DThrift build instructions).  I then 
ran

C:\Tools\D\dmd2\windows\local\lib>..\..\bin\coffimplib 
C:\Tools\OpenSSL-Win32\li
b\libeay32.lib libeay32.omf.lib
C:\Tools\D\dmd2\windows\local\lib>..\..\bin\coffimplib 
C:\Tools\OpenSSL-Win32\li
b\ssleay32.lib ssleay32.omf.lib

to convert the given import libs to OMF as suggested.  (Note, I 
suspect these are not the VC import libs, but I don't know what 
compiler they came from.  Gcc?)  I have deimos openssl D bindings 
in my import path and the above windows\local\lib folder in my 
link path.  I compile with:

C:\DSockets>dmd server.d ssleay32.omf.lib libeay32.omf.lib

and all is well.

If I then put the OpenSsl .DLLs from  in the same directory
When I run the server program, I quickly get a run-time error:

C:\DSockets>server
OPENSSL_Uplink(005A0000,08): no OPENSSL_Applink

The openssl.org faq says:
    "Note that debug and release libraries are NOT 
interchangeable. If you built OpenSSL with /MD your application 
must use /MD and cannot use /MDd.
    "As per 0.9.8 the above limitation is eliminated for .DLLs. 
OpenSSL .DLLs compiled with some specific run-time option [we 
insist on the default /MD] can be deployed with application 
compiled with different option or even different compiler. But 
there is a catch! Instead of re-compiling OpenSSL toolkit, as you 
would have to with prior versions, you have to compile small C 
snippet with compiler and/or options of your choice. The snippet 
gets installed as <install-root>/include/openssl/applink.c and 
should be either added to your application project or simply 
#include-d in one [and only one] of your application source 
files. Failure to link this shim module into your application 
manifests itself as fatal "no OPENSSL_Applink" run-time error. An 
explicit reminder is due that in this situation [mixing compiler 
options] it is as important to add CRYPTO_malloc_init prior first 
call to OpenSSL."

Ignoring this last cryptic reminder, I *do* see applink.c in the 
SLP Openssl include directory.  But I don't see any D 
binding/equivalent file for it.  I also don't see any ?pplink 
strings in the map file when compiling server.d  so it's 
certainly not provided if it's required.  The question is where 
should it come from and whether it's always required.  The faq 
answer makes me think if I had a different version of the import 
libs, I might not need any applink stuff.  And I don't see any of 
the other "howto" pages suggesting this is needed.  If I *do* 
need to supply it myself, how should I do that?  Just compile 
their .c to a .obj and add it to the dmd command line?  Surely 
some D binding would be better...

Count this as another vote for a little more comprehensive 
documentation on how to get OpenSSL DLLs working under windows.  
This is the kinda thing that makes folks think maybe C++ is still 
tolerable...

For completeness, I'm running

C:\DSockets>dmd --help
DMD32 D Compiler v2.060

on Windows 7 64-bit

Any input greatly appreciated.
Jason


On Monday, 9 July 2012 at 13:45:18 UTC, David Nadlinger wrote:
> I described the installation of Thrift (which also uses 
> OpenSSL) on Windows here: 
> https://github.com/klickverbot/thrift/wiki/Building-Thrift-D-on-Windows
>
> In the build system, I just add the generated import libraries 
> to the command lines afterwards (like a source file, without 
> any special switch).