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