OpenSSL Lib Naming Scheme

[dougswanson]

Why does POCO NetSSL_OpenSSL link to OpenSSL import libraries on Windows using the following naming scheme (from Crypto.progen or NetSSL_OpenSSL.progen

vc.project.linker.dependencies.debug_shared = libeay32.lib ssleay32.lib
vc.project.linker.dependencies.release_shared = libeay32.lib ssleay32.lib
vc.project.linker.dependencies.debug_static_md = libeay32.lib ssleay32.lib
vc.project.linker.dependencies.release_static_md = libeay32.lib ssleay32.lib
vc.project.linker.dependencies.debug_static_mt = libeay32mtd.lib ssleay32mtd.lib Crypt32.lib
vc.project.linker.dependencies.release_static_mt = libeay32mt.lib ssleay32mt.lib Crypt32.lib

Why do the static_mt configurations use names like libeay32mt.lib, but the static_md and shared configurations both use libeay32.lib? How do you distinguish a static /MD build of OpenSSL from a dynamic import library build of OpenSSL? (They both use libeay32.lib). Or are the static_md configurations meant to link dynamically to OpenSSL, even though they build POCO static libs?

Thanks,

[dougswanson]

bump? Basically, we just want to know what version of OpenSSL (static lib with /MD, or shared/dynamic lib with import library) is referred to by each 'libeay32.lib'.

[dougswanson]

bump? Thanks,

[guenter]

It's basically because we want it to work out of the box with a normal OpenSSL installation created by the Shining Light installer. Unfortunatly, the way the installer creates the lib directory provides for some challenges. First, there's no real distinction between debug and release builds - import libs for both are provided, but both are the same, as there are no real debug-build DLLs. So I decided to handle it in such a way that we pick up the import libs for debug_shared and release_shared from OpenSSL-Win32/lib (libeay32.lib, ssleay32.lib) and for static builds from OpenSSL-Win32/lib/VC/static. This allows you to set both global lib search paths (to OpenSSL-Win32/lib and OpenSSL-Win32/VC/static) and allow the linker to find the correct import libs - mostly. The debug_static_md and release_shared_md configurations are a bit inconsequential, as they'll link with the OpenSSL DLLs. OTOH, static_md means statically linked POCO and runtime lib DLLs, so if you consider OpenSSL a runtime lib, this makes sense. The correct OpenSSL import libraries to use would be in OpenSSL-Win32/lib/VC, but they are named the same as the import libs in lib/VC/static, so there's your mess...

The ultimate solution would be to create a version of NetSSL that uses the native Windows SSL/TLS API (SChannel). We basically have this, but it's based on a very old version of NetSSL and would need heavy updating. If someone wants to do this let me know and I'll put the code on GitHub.

[dougswanson]

Thanks guenter. If I understand you correctly, then it would work equally well to keep OpenSSL-Win32/lib/VC/static in the linker search path (it's there for static_mt configurations anyway), and just change the POCO build scripts to link against libeay32md.lib and libeay32mdd.lib for release_static_md and debug_static_md respectively (if we want to statically-link OpenSSL also). Right?

[dougswanson]

guenter? Did I get that right? Thanks,

[guenter]

I don't think this will work, as the OpenSSL libs in lib/VC/static are linked statically against the VC runtime, while the rest of your app will link against the VC runtime DLLs. You'll have to try it out, but you may end up with linker errors (multiply defined symbols). Correct approach would be to link against the import libs in lib/VC, but then you can't keep the search path to /lib/VC/static. I think I'm getting a headache from all this...

[dougswanson]

Wait a moment. VC/lib/static means "statically linked against the runtime"? No, that can't be right -- VC/lib/static must mean "static lib", because there are libeay32md.lib and libeay32mdd.lib inside VC/lib/static, and those presumably are static libs but dynamically linked against the runtime.

[dougswanson]

guenter? bump?

[dougswanson]

guenter? bump?