> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Ken Goldman > Sent: Thursday, March 21, 2019 13:44 > To: openssl-users@openssl.org > > On 3/20/2019 12:41 PM, Michael Wojcik wrote: > > > > > 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. > > ar t libcrypto.lib returns about 4100 lines of: > > libcrypto-1_1-x64.dll > libcrypto-1_1-x64.dll > ... > > So it's an 'import library'. But I get link errors, with each openssl > function missing. > > Any clues?
Without picking at the problem files myself, not really. It's probably something that will be fairly obvious in retrospect but I'm not seeing it from here. The import libraries (I'm assuming libssl.lib is one as well, on your system) basically tell the linker "for this symbol, insert a runtime load reference to this DLL". The Cygwin nm can display the symbols in an import library; I don't remember if MingW includes nm, or know if it understands import libraries. So well-formed import versions of libcrypto.lib and libssl.lib should name all the public OpenSSL symbols, and you shouldn't get resolution errors when linking against them. You might well get resolution errors at runtime, if the corresponding DLLs can't be found; but not a link time. I seem to have discarded some of your older messages. Did you ever send us the actual link command that's being used? Maybe that will throw some light on the problem. -- Michael Wojcik Distinguished Engineer, Micro Focus
