Using (not building) openssl with mingw on Windows 10

Michael Wojcik Michael.Wojcik at
Wed Mar 20 16:41:41 UTC 2019

> From: openssl-users [mailto:openssl-users-bounces at] On Behalf Of
> Ken Goldman
> Sent: Wednesday, March 20, 2019 08:46
> To: openssl-users at
> Subject: Re: Using (not building) openssl with mingw on Windows 10
> On 10/29/2018 7:18 AM, Jakob Bohm via openssl-users wrote:
> > Note that Win32 (Microsoft) .LIB files are actually standard unix-style
> > .a files with the file names changed to match the the historic
> > MS-DOS/Win16 practice (which had a different file format).
> >
> > So it is highly likely the .LIB files can be used with mingw by just
> > copying/symlinking them, or even just using a Mingw option to load
> > .LIB files.
> >
> > Beware however of the crazy GNU interpretation that listing a library
> > file explicitly means include *all* the code from the library, not
> > just the referenced object files.
> Getting back to this:
> I tried mingw linking against these
> "c:/program files/openssl64/lib/libcrypto.lib"
> "c:/program files/openssl64/lib/libssl.lib"
> but the gcc linker failed to find the openssl functions.
> Anyone have any ideas?
> ~~
> I observe that the .a file is 3 mb while the .lib is 900k.

Sounds like you might have import libraries there. Does "ar t libcrypto.lib" show a bunch of .obj members, or a bunch of .dll members? If it's the latter, then it's just an import library that tells the linker what DLL needs to be loaded at runtime.

We build static (non-import) OpenSSL libraries for Windows, but at least for 1.0.2 we had to tweak the configuration process. The stock Configure wanted to link OpenSSL with the static Microsoft C runtime if you were building static libraries, whereas we wanted static libraries linked with the dynamic runtime. (I don't remember offhand if we had to do the same for 1.1.1.)

Michael Wojcik
Distinguished Engineer, Micro Focus

More information about the openssl-users mailing list