On 6/19/2015 1:11 PM, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Jay Foster
Sent: Friday, June 19, 2015 15:51
I got my application to compile and link. It seemed to run OK, but when
I tried to run it on a different Windows machine, it failed with a pop
up dialog complaining it could not find LIBEAY32.dll. I 'thought' I was
statically linking this library, but apparently not. I have no idea how
it worked on the one machine. What is the magic incantation to get
Visual Studio to statically link the OpenSSL libraries?
The OpenSSL libraries have to be built as static libraries.
If you configure the OpenSSL build for static libraries, that's what you'll get.
If you configure it for dynamic libraries, you'll get libeay32.dll and ssleay32.dll, and
a pair of "import libraries" named libeay32.lib and ssleay32.lib. You won't get
static libraries at all. Note the static libraries and the import libraries have the same
name.
When you link a library to a Windows executable, you provide either a static
library or an import library. In the latter case, the executable will do an
implicit load of the corresponding DLL at startup.
So if you want to statically link with OpenSSL, you have to configure it for
static linkage and build it that way. Then the libeay32.lib and ssleay32.lib
you get should be true static libraries and not import libraries.
I think "no-shared" is the Configure option you need. We actually have a script
that changes some of the OpenSSL makefiles after configuring, so our process is a bit
different from yours.
That sounds like what I'm running into. I rebuilt the OpenSSL libraries
with the "no-shared" option, but this made no difference. Does that work
for Windows?
Jay
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
