PERL CPAN Module Crypt::SSLeay on OVM V8.2

[Steven Coghill]

We are trying to install Crypt::SSLeay
(http://search.cpan.org/CPAN/authors/id/C/CH/CHAMAS/Crypt-SSLeay-0.51.tar.gz) and are having major problems.

We currently run three Alpha clusters under OVMS V7.3-1 with PERL V5.6.1. We created an OVMS Alhpa V8.2 system for testing migrating our application to 8.2. We were able to download all the current CPAN modules we use and rebuild them with no problems except for Crypt::SSLeay.

First problem was the PERL MAKEFILE.PL build an incorrect DESCRIP.MMS file. We had to modify it to point to the OpenSSL libraries. Once that was corrected we build the module (MMK) and did an MMK test. The test failed with an ACCVIO. Our application scripts get an ACCVIO when we run them against the PM.

Has anyone had success in getting Crypt::SSLeay running on Alpha V8.2? If so, what did you do to make it work.

I am attaching the e-mail I sent to HP to see if they could give any help.

[Sebastian Bazley]

The VMS Perl mailing list might be useful:

Vmsperl@perl.org

list-help:
list-unsubscribe:
list-post:

Try their archives (sorry, don't have URL handy)

[Craig A Berry]

Your posting says you are using Perl 5.6.1 but your attached e-mail says you are using 5.8.6. In Perl 5.8.x, IEEE floating point format became the default. If that doesn't match what your SSL libraries were built with, that could be a problem, though I don't know offhand if accvio would be the symptom.

That's just a guess. I'll try a debug build and see if I spot anything right off.

[Craig A Berry]

I think I found the problem. You're right that the Makefile.PL needs a little VMS-specific help, but it mostly does the right thing if you tell it to look for SSL in /ssl$root. That will make it find the include files. However, you still have to make it find the shareable images to link against.

If you did what I did, you checked in SYS$LIBRARY and just linked against what was there:

$ dir/nohead/notrail sys$library:ssl$*.exe
SYS$COMMON:[SYSLIB]SSL$LIBCRYPTO_SHR.EXE;1
SYS$COMMON:[SYSLIB]SSL$LIBCRYPTO_SHR32.EXE;1
SYS$COMMON:[SYSLIB]SSL$LIBSSL_SHR.EXE;1
SYS$COMMON:[SYSLIB]SSL$LIBSSL_SHR32.EXE;1

BUT, if you link against the ones without a "32" at the end of the name, you'll get a successful link but the accvio when you run the tests, as you discovered. I'm guessing those are libraries that expect 64-bit pointers. Unless you have built your own 64-bit Perl, those are the wrong libraries. When I relinked against the ones with "32" in the name, the tests ran successfully.

Here's what my linker options file looks like, where the last two lines I added manually after running the Makefile.PL:

$ type ssleay.opt
SYMBOL_VECTOR=(boot_Crypt__SSLeay=PROCEDURE)
[.blib.arch.auto.Crypt.SSLeay]SSLeay.olb/Include=SSLeay
[.blib.arch.auto.Crypt.SSLeay]SSLeay.olb/Library
PerlShr/Share
sys$library:ssl$libcrypto_shr32.exe/share
sys$library:ssl$libssl_shr32.exe/share

It shouldn't be that hard to modify the Makefile.PL to do the right thing on VMS, but I can't promise I'll get around to it anytime soon.

[Craig A Berry]

Well, I got to it sooner than I thought. The attached patch to Crypt::SSLeay 0.51 will get it to build and test on VMS without incident. It assumes the current HP SSL kit, v1.2 (or, I would hope, later). You appear to be running some other, perhaps older, kit, so this won't do you any good unless you first upgrade your SSL installation.

If you don't want to change your SSL installation, it is still liklely you are linking against 64-bit instead of 32-bit libraries and correcting this will get you up and running.