Using version - Perl-5.36
I have Net-SSLeay installed
Looking for solutions, I added the ssleay32.dll to the PATH variable identified in this article - perl - Why can't DynaLoader.pm load SSleay.dll for Net::SSLeay and Crypt::SSLeay? - Stack Overflow
These are the only packages I am using:
use IO::Socket::SSL;
use LWP::UserAgent;
Also have this installed - LWP::Protocol::https;
Any ideas on how to get this resolved?
SSLeay.dll has a dependency on the OpenSSL dll. Not being able to find the version of OpenSSL that ssleay.dll is expecting is often the reason this error appears.
Did you “activate”, or “deploy” to install this 5.36 runtime? That might make a difference, but since we don’t have other reports of this, the odds are pretty good that your system has an incompatible version of OpenSSL that has been installed by third party software into the System32 folder tree, and that that dll is the one that dynaloader attempts to provide for ssleay.dll.
Thanks for the reply. I have Git installed and I believe includes OpenSSL and Git was also in the path variable. I built the package on ActiveState, ran the CLI Utility installer and then did a state pull, which put everything under the cache directory on Windows.
Also, assuming this related to my local env, since I got a similar error with another package: Can’t load ‘C:/Users/…/AppData/Local/ActiveState/cache/…/site/lib/auto/XML/LibXML/LibXML.dll’ for module XML::LibXML: load_file:The specified module could not be found…
Looks like all related to .dll getting loaded, just not sure how to fix it. thanks
If you see this kind of error with multiple packages, there may be something else involved. Some security suites can blacklist ‘unknown’ locations such as folders in user AppData, preventing binary dll files from those locations from loading even if they are on the path.
You might be able to temporarily disable your security suite to see if the issues clear up, or you might be able to try the same project on a different PC which doesn’t have the security suite installed to see if that might be a factor.
Alternately, you might try “state deploy” instead of “state activate” and place the Perl folder somewhere that a security suite might be happier with.