I'm not a C++ dev so pardon my ignorance, but I'm trying to understand this paragraph,
The libeay32MT version under \VC\lib\ is supposed to be statically linked to the MSVC runtimes but not a static library itself, right? But
when using /MD for dynamic linking to the statically linked libeay32MT in order to not have to bundle MSVC runtimes, which means
having to ship the .dll along with the application, the dll itself requires the runtime. Have not found any different pre-installed versions of
the dlls that are statically linked.
My understanding is that /MD flag links to runtime with dependency on msvcr<versionNumber>.dll whereas /MT flag is conventional static linking. So isn't it the latter flag that you want here?
No, that's not right. /MD is a compiler flag which tells it to make a dynamically loadable module, whereas /MT tells it to create a static library.
That has nothing to do with how the C/C++ runtimes were linked, which is done by linker not compiler and can be either statically or dynamically.
So in essence can build either static libraries (/MT) or dynamic libraries (/MD) which are linked either statically or dynamically to their C/C++ runtimes for a total of 8 permutations.
This is why there are 8 versions of the openssl libraries, two dynamic libraries, libeay32MD and libeay32MT, referring to dynamic or static linking to MSVC runtimes, and static/libeay32MT, static/libeay32MD for static library of the same. static/libeay32MD is a static library with dynamic linking to MSVC runtimes which in some scenarios is preferred.
In this case only building a dynamic library is an option as it is a library to be loaded into application, not a stand alone program. So /MD compiler flag with dynamic openssl libraries is the only option. The use case does require static links to MSVC runtimes, however, so as not to require the user to install them.
The issue as far as I can see is that the dynamic libeay32MT versions of the library are lacking their equivalent statically linked with MSVC runtimes .dlls to distribute with. libeay32MT does not require MSVC runtimes but the dlls do, making the *eay32MT libraries moot. These dlls are available in other binary distributions ( https://indy.fulgan.com/SSL), but not in the pre-installed appveyor openssl.
For reference, the env variable or cmake flag to link with static MSVC runtimes is OPENSSL_MSVC_STATIC_RT. This in turn compiles against *eay32MT. It is separate from OPENSSL_USE_STATIC_LIBS which will compile against static/<..>.
Should also point out that linking against static MT libraries but compiling with /MD for a dynamic library is also not an option.
That requires that the same compiler was used for both the library to be linked as well as the dynamic library or the MSVC run times will not match, resulting in errors.
Unfortunately the only option, other than downloading statically linked dlls from another distribution, is to build OpenSSL on every job with multiple compilers - not a very attractive option to say the least.
Again, apologies for not having too much experience with the subtleties of c++ static/dynamic linking. But, if you'll indulge me, I've a simple question... What is the difference between the 'libeay32.dll' at C:\OpenSSL-Win32 on the AppVeyor build image and the one of the same name in the binary distributions you linked to?
No worries, not too familiar with these windows specifics either.
The difference is the ones in C:\OpenSSL-Win32 are linked dynamically with MSVC run times meaning they require the MSVC dlls where as the ones from the other binary distribution are linked statically and do not.
Have attached dependency walker screenshots for each with the openssl dll dependencies circled. The one from appveyor has a dependency on msvcr120.dll whereas the other does not.