| |
| Posted by Jason Spencer in reply to David Nadlinger | PermalinkReply |
|
Jason Spencer
Posted in reply to David Nadlinger
| 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).
|