openssl/NOTES.VMS
Richard Levitte 1ae4c07e50 VMS: don't use /DSF, turn off CALL_DEBUG instead
It turns out that /DSF didn't do any good for our purposes.  Instead,
remove the CALL_DEBUG flag from any image we link.  This ensures that
we can have debugging information in the image files, but don't
automatically end up in a debugging session upon image activation.

Unfortunately, this means the CALL_DEBUG must be turned on when there
is a need to run with the debugger activated, and to turn it off when
done.  This has been documented in NOTES.VMS.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2957)
2017-03-15 03:09:57 +01:00

101 lines
3.4 KiB
Text

NOTES FOR THE OPENVMS PLATFORM
==============================
Requirement details
-------------------
In addition to the requirements and instructions listed in INSTALL,
this are required as well:
* At least ODS-5 disk organization for source and build.
Installation can be done on any existing disk organization.
About ANSI C compiler
---------------------
An ANSI C compiled is needed among other things. This means that
VAX C is not and will not be supported.
We have only tested with DEC C (a.k.a HP VMS C / VSI C) and require
version 7.1 or later. Compiling with a different ANSI C compiler may
require some work.
Please avoid using C RTL feature logical names DECC$* when building
and testing OpenSSL. Most of all, they can be disruptive when
running the tests, as they affect the Perl interpreter.
About ODS-5 directory names and Perl
------------------------------------
It seems that the perl function canonpath() in the File::Spec module
doesn't treat file specifications where the last directory name
contains periods very well. Unfortunately, some versions of VMS tar
will keep the periods in the OpenSSL source directory instead of
converting them to underscore, thereby leaving your source in
something like [.openssl-1^.1^.0]. This will lead to issues when
configuring and building OpenSSL.
We have no replacement for Perl's canonpath(), so the best workaround
for now is to rename the OpenSSL source directory, as follows (please
adjust for the actual source directory name you have):
$ rename openssl-1^.1^.0.DIR openssl-1_1_0.DIR
About MMS and DCL
-----------------
MMS has certain limitations when it comes to line length, and DCL has
certain limitations when it comes to total command length. We do
what we can to mitigate, but there is the possibility that it's not
enough. Should you run into issues, a very simple solution is to set
yourself up a few logical names for the directory trees you're going
to use.
About debugging
---------------
If you build for debugging, the default on VMS is that image
activation starts the debugger automatically, giving you a debug
prompt. Unfortunately, this disrupts all other uses, such as running
test programs in the test framework.
As a compromise, we're turning off the flag that makes the debugger
start automatically. If there is a program that you need to debug,
you need to turn that flag back on first, for example:
$ set image /flag=call_debug [.test]evp_test.exe
Then just run it and you will find yourself in a debuggin session.
When done, we recomment that you turn that flag back off:
$ set image /flag=nocall_debug [.test]evp_test.exe
Checking the distribution
-------------------------
There have been reports of places where the distribution didn't quite
get through, for example if you've copied the tree from a NFS-mounted
Unix mount point.
The easiest way to check if everything got through as it should is to
check for one of the following files:
[.crypto]opensslconf^.h.in
The best way to get a correct distribution is to download the gzipped
tar file from ftp://ftp.openssl.org/source/, use GZIP -d to uncompress
it and VMSTAR to unpack the resulting tar file.
Gzip and VMSTAR are available here:
http://antinode.info/dec/index.html#Software
Should you need it, you can find UnZip for VMS here:
http://www.info-zip.org/UnZip.html