Seems to me there were at least 4 problems (and some confusion exacerbated by one or more of those) explored in this thread.
- The OPs original problem (RESOLVED?*):
(*)Had the OP just not attempted to install Crypt::SSLeay at this point?
Failed to GET 'https://www.helsinki.fi/':
501 Protocol scheme 'https' is not supported
(Crypt::SSLeay not installed) at testSSL.pl line 19.
- The OP's secondary problem once he installed Crypt::SSLeay(UNRESOLVED*):
(*)I agree that this error could not have occured if the DLL came from a PPM distribution. What is the OP not telling us?
$ perl -MCrypt::SSLeay -e "print 'OK'"
Can't find 'boot_Crypt__SSLeay' symbol
in c:/Perl/site/lib/auto/Crypt/SSLeay/SSLeay.dll
- The problem with using PPM from AS1000 (RESOLVED*)
(*)for AS1000, but the OP apparently had the same problem with AS1002?
ppm install http://cpan.uwinnipeg.ca/PPMPackages/10xx/Crypt-SSLeay.ppd
ppm install failed: The PPD does not provide code to install for this
+platform
Which combined with (differential) displaying by the servers or browsers of the XML contents of PPDs:
OpenSSL glue that provides LWP https support
Joshua Chamas <josh (at) chamas dot com> install_ssl
- The build failure of Crypt::SSLeay when using the generated makefile (UNRESOLVED):
link -out:blib\arch\auto\Crypt\SSLeay\SSLeay.dll
-dll -nologo -nodefaultlib -debug -opt:ref,icf
-libpath:"C:\Perl\lib\CORE"
-machine:x86 SSLeay.obj
C:\Perl\lib\CORE\perl58.lib
c:\cl\lib\oldnames.lib c:\cl\lib\kernel32.lib c:\cl\lib\user32.lib
c:\cl\lib\gdi32.lib c:\cl\lib\winspool.lib c:\cl\lib\comdlg32.lib
c:\cl\lib\advapi32.lib c:\cl\lib\shell32.lib c:\cl\lib\ole32.lib
c:\cl\lib\oleaut32.lib c:\cl\lib\netapi32.lib c:\cl\lib\uuid.lib
c:\cl\lib\ws2_32.lib c:\cl\lib\mpr.lib c:\cl\lib\winmm.lib
c:\cl\lib\version.lib c:\cl\lib\odbc32.lib c:\cl\lib\odbccp32.lib
c:\cl\lib\msvcrt.lib
-def:SSLeay.def
...
blib\arch\auto\Crypt\SSLeay\SSLeay.dll : fatal error LNK1120: 50 unres
+olved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.
No mention of the required libraries on the generated build command despite that it knows that they are required:
BUILD INFORMATION
================================================
ssl library: OpenSSL 0.9.8 in c:\openssl
ssl header: openssl/ssl.h
libraries: -Lc:\openssl\lib -lssleay32 -llibeay32
include dir: -Ic:\openssl\include
================================================
Add to that, the "libpath" switch -Lc:\openssl\lib, won't work with the latest distributions (I don't know about earlier ones) of openssl because the libraries are located in subdirectories below that path. And the libraries themselves have different names.
But that doesn't explain why neither the (wrong) libpath nor the library names showed up in the generated commands?.
There's not much more can be done unless the OP starts coming clean about what he had done prior to each of the two problems he had.
Nor unless the maintainer decides to get involved again.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] [select] |
(*)for AS1000, but the OP apparently had the same problem with AS1002?
No, I don't think he had the same problem. He said that at one stage he got:
ppm install http://theoryx5.uwinnipeg.ca/ppms/Crypt-SSLeay.ppd
ppm install failed: The PPD does not provide code to install for this
+platform
But what he was doing there was trying to install a 5.8 package into 5.10. PPM rightly refused to do that and gave the correct reason.
No mention of the required libraries on the generated build command despite that it knows that they are required
If the libraries do not get found at the 'perl Makefile.PL' stage then MakeMaker doesn't include them in the generated build command. (If they can't be found then including them in the command is only going to produce a "no such file" fatal error.)
Other than that, I think you've got it pretty right :-)
Cheers, Rob | [reply] [d/l] |
If the libraries do not get found at the 'perl Makefile.PL' stage then MakeMaker doesn't include them in the generated build command. (If they can't be found then including them in the command is only going to produce a "no such file" fatal error.)
Hm. But at least I'd know what it was looking for, could go look for them, tweak the LIB path in the environment and re-run the make.
That's a far easier process than trying to a) figure out what libraries I should be looking for and then b) work out how to modify makefile.pl to have it either look in the right places or add the appropriate libpath, then c) re-gen the makefile, then d) see if it worked....
I just don't get the philosophy behind EU::MM. It turns the whole easy things easy, hard things possible upside down. Not so much OO, more like spagetti hoops :(
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] |