On 6/19/2015 1:11 PM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at 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
