Using (not building) openssl with mingw on Windows 10

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Ken Goldman
> Sent: Wednesday, March 20, 2019 08:46
> To: openssl-users at openssl.org
> 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