Using (not building) openssl with mingw on Windows 10
Michael.Wojcik at microfocus.com
Wed Mar 20 16:41:41 UTC 2019
> 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.)
Distinguished Engineer, Micro Focus
More information about the openssl-users