error:140A90F1:SSL routines:SSL_CTX_new:unable to load ssl2 md5 routines

Find the following information:

http://comments.gmane.org/gmane.comp.lib.boost.asio.user/2099

Well I think I have figured out what the issue is, or at least narrowedit down. I have been able to provide a work around for our needs but Iwanted to post this in case someone came across this same issue.It appears to be an issue with some type of static member initializationinside the openssl library. I have 2 libraries, both of them use theopenssl library, let's call them A and B. When the application starts upboth A & B are able to successfully create a security context. Later,when library B tries to create another security context it fails. Bothlibrary A and B are module plugins to our application so they both willload but if one is not needed it is unloaded. So once I realized that, Iran some experiments.If just A is loaded then things work fine.If just B is loaded then things work fine.If A and B are loaded, then A is unloaded, B failsIf A and B are loaded, then B is unloaded, A failsIf A is loaded, then unloaded, then B is loaded, B works fineIf B is loaded, then unloaded, then A is loaded, A works fineSo, my belief is that when openssl is loaded it initializes some staticmembers. Once a library that uses openssl is unloaded openssl clearssome needed state that prevents anyone else from creating a security
context.

Our temporary, and probably very bad, solution to this problem was to eliminate the call to EVP_Cleanup() in the digestOfBytes() method.

What apparently was happening is something like this: the Perl libraries that we were importing use openSSL, and load tables through something like OpenSSL_add_all_x. Because EVP_Cleanup()is global, the Perl libraries (probably LWP::Protocol::https) couldn't find the tables of algorithms when they went to look them up.

While this works, I'd really prefer to do something safer... not cleaning up seems like a sloppy solution.