Since there are so many things it can't find, it probably didn't find libssl-1_1.dll at all.
Normally, libssl-1_1.dll would only need to be found at run-time - and this is easily achieved by simply ensuring that the location of that dll is included in the PATH environment variable.
Also, I have this notion (from way back in the distant past when I used to build a lot of stuff on windows) that, if the build were being done against a shared library (dll), then the undefined symbols would all begin with something like imp_ or __imp_... and they don't. So I'm thinking the build is being done against static OpenSSL libraries.
(Is that notion of mine correct ?)
The errors that the OP is reporting are happening at link-time.
The thing that irritates me a little is that if the OP could be bothered installing Strawberry Perl 5.32.x (where 'x' is either '0' or '1') then he could simply run cpan -i Net::SSLeay and end up with a Net-SSLeay-1.90 installation that was built against OpenSSL-1.1.1g.
If it really needs to be built against OpenSSL-1.1.0, then he could install Strawberry Perl 5.28.x (which ships with OpenSSL-1.1.0h) and then run cpan -i Net::SSLeay.
Alas, I get the impression that there might also be the stipulation that the upgrade to Net-SSLeay-1.90 be achieved via some unknown and unnecessary batch script.
But we have very few details ....
Cheers,
Rob
| [reply]
[d/l]
[select] |
