Build and Install Perl for Stratus OpenVOS

You will finish with a source build and installation plan for Perl on a Stratus V Series system running OpenVOS. The guide follows the perlvos notes shipped with Perl 5.38.2 on this machine, whose port instructions require OpenVOS 17.1.0 or later, GNU Tools 3.5 or later, and the C/POSIX Runtime Libraries.

Allow roughly 30 to 60 minutes, excluding time to obtain the source tree and platform tools. You need access to an OpenVOS system, a shell with bash, the Perl source, and write permission in the installation tree. This is a build and installation task, so make a maintenance window and a recovery copy of any existing installation before replacing files.

1. Confirm that this is the right port

perlvos is not a general Perl command reference. It documents building Perl for the Stratus OpenVOS operating system. The documented port needs dynamic linking support from OpenVOS Release 17.1, so OpenVOS 17.0 and earlier releases are outside this procedure.

Check the operating-system and tool versions before unpacking or configuring anything:

$ uname -a
$ gmake --version
$ perl -v

The exact version-reporting commands can vary with the OpenVOS installation. The checkpoint is a documented OpenVOS release of at least 17.1.0, GNU Tools of at least 3.5, and a working C/POSIX Runtime Libraries installation. If any prerequisite is missing, stop and obtain it through the system owner or Stratus support channel. Do not try to compensate by copying Linux libraries onto OpenVOS.

2. Prepare the source build

Use the normal Perl source-build flow, but perform it inside bash. Change to the unpacked Perl source directory and run its Configure script:

$ bash
$ cd /path/to/perl-source
$ ./Configure

Replace /path/to/perl-source with the directory containing the source you intend to build. Read each prompt rather than accepting settings copied from a different operating system. The perlvos document does not define an OpenVOS-specific replacement for the standard configuration process.

Checkpoint: configuration should finish without a missing compiler, linker or runtime-library error. If it fails, keep the complete diagnostic and correct the prerequisite rather than moving on to gmake. A configured tree is not yet an installed Perl, and a successful configuration does not prove that every module will work on your target release.

3. Build with GNU make

Start the build with GNU make, named gmake in the port notes:

$ gmake

Watch for a non-zero exit status. If the build stops, capture the first meaningful compiler or linker error, then fix that issue and rerun the build from the same source tree. Do not delete the tree as a first response: the generated configuration and logs can be useful when diagnosing a library or platform mismatch.

Checkpoint: only proceed when gmake completes successfully. The useful result is a built Perl executable for OpenVOS, not merely a directory full of object files. Run the source tree's available smoke checks if your Perl release supplies them, but treat those checks as evidence rather than a guarantee of application compatibility.

4. Protect the installation destination

The documented installation destination is >system>ported and its subdirectories. Before installing, confirm that you have both modify permission and default write permission there. This is the point where an ordinary build becomes a system-wide change, so use the account and change process required by your OpenVOS installation.

Do not overwrite an existing Perl installation blindly. Record the current version and preserve a rollback copy or snapshot according to local operations practice. If you cannot recover the previous tree, stop before the install step. An install can affect scripts and site modules that use the shared Perl search path.

5. Install the built Perl

From the successfully configured and built source directory, run:

$ gmake install

This command changes the OpenVOS installation tree and may require elevated or specially delegated permissions. It is not a command to run on a Linux workstation merely because the Linux machine has a perlvos manual page. If the command fails with a permission error, stop and fix the destination permissions or use the approved installation account. Do not make the whole system writable as a shortcut.

Checkpoint: verify the installed interpreter with the OpenVOS command used by your site, then check its version and search path:

$ perl -v
$ perl -e 'print join("\n", @INC), "\n"'

The output should identify the version you built and list the directories that Perl searches. The exact formatting is version-dependent. If the shell still finds an older Perl, inspect the command path and environment before changing application scripts. Undo a mistaken installation by restoring the preserved installation tree using your normal OpenVOS recovery procedure; do not remove directories by guesswork.

6. Place site modules in the matching tree

The port notes separate architecture-independent site modules from architecture-dependent files. For a Perl version represented by VERSION, use these documented locations:

>system>ported>lib>perl5>site_perl>VERSION
>system>ported>lib>perl5>site_perl>VERSION>i786

Put portable site files in the first directory. Put files tied to the architecture in the second. Replace VERSION with the installed Perl version; do not leave the literal word in a production path. The i786 directory is the architecture-specific location named by these port notes, so confirm that it matches the binaries and conventions supplied by your OpenVOS release before adding native code.

Use Perl itself to inspect the effective order rather than assuming that a directory is active:

$ perl -e 'print join("\n", @INC), "\n"'

A module can appear to be installed while Perl searches a different version directory. Keep site modules versioned and test the application under the exact interpreter that will run it.

7. Test dates and application behaviour

OpenVOS Perl uses Unix-epoch date values internally, with a supported range from 1 January 1980 to 17 January 2038. ASCII date strings are less affected by that internal representation, but code that stores or calculates epoch values needs tests near the boundaries.

Run the application test suite on OpenVOS, including file paths, date handling, native extensions and external commands. The port notes warn that some Perl self-tests fail because OpenVOS POSIX behaviour differs from common POSIX systems. Treat a failing test as a compatibility investigation, not as permission to ignore all test results. Record which failures are understood and which prevent release.