Home / Alt manpages / perlhpux(1)

  • perlhpux(1)
  • User command
  • linux

Build a Compatible Perl for HP-UX

You will finish with a Perl build plan that matches the HP-UX machine's processor, compiler and library model, plus checks for the mistakes that usually appear only when an extension is loaded. The installed reference here is Perl 5.38.2, but perlhpux(1) describes several older HP-UX releases, so its historical examples need to be read as version-specific guidance.

Allow thirty to sixty minutes for a prepared source tree, longer if you need a compiler or depot. You need an HP-UX shell, Perl source, an ANSI C compiler, enough disk space, and permission to install software. Ordinary inspection and compilation can be unprivileged. swinstall, writing under system directories, and changing the kernel require the relevant HP-UX administration privileges.

1. Identify the machine and the installed Perl

Start by recording the machine model and architecture. This decides whether you are building for PA-RISC or Itanium, and it prevents a plausible-looking binary from being copied to the wrong family.

$ model
$ /usr/contrib/bin/machinfo
$ perl -V:version

The manual uses model for the short hardware identity and /usr/contrib/bin/machinfo for broader machine information. On a system supplied with Perl by HP, inspect the depot rather than guessing which build is present:

# swlist -R perl

That command is read-only. The output may separate 32-bit and 64-bit runtime and manual-page components. Keep the output with your build notes, especially if the target application links to a 64-bit library.

2. Choose a real ANSI C compiler

Do not use the traditional K&R C compiler that ships with HP-UX. perlhpux(1) requires an ANSI C compiler and recommends HP's ANSI C compiler because it supports the HP-specific flags used elsewhere in the document. GCC can work, but it must be a complete, sufficiently recent build with the required 32-bit or 64-bit support.

$ command -v cc
$ cc -V
$ command -v gcc
$ gcc --version

With HP's compiler, recent Perl source normally adds -Aa automatically. If you are reviewing an older source tree or its generated config.sh, check that the ANSI mode is present in the cpprun and cppstdin settings. Do not silently substitute whichever compiler happens to be first in PATH.

Checkpoint: you should be able to name the compiler, its bitness, and the libraries that the target program must use. If you cannot, stop before running Configure.

3. Select the bitness before configuring

On PA-RISC, 32-bit and 64-bit objects do not mix. If the application needs 64-bit libraries, such as an Oracle 64-bit client, Perl must also be a 64-bit build. On Itanium, a PA-RISC Perl is not a safe substitute: shared libraries from the two executable families are not interchangeable.

For a pure LP64 build, pass -Duse64bitall to Configure. The HP compiler uses +DD64; GCC uses the compiler's corresponding 64-bit support, with -mlp64 on Itanium. The manual also documents -Duse64bitint, but recommends choosing the explicit Configure flag instead of answering the later interactive questions and hoping the resulting combination is coherent.

$ sh Configure -Duse64bitall

Use the command that matches your source release. Configure is interactive and may ask about paths, compiler settings and libraries. Read each answer before accepting it. A 64-bit Perl built against 32-bit extension libraries will fail later, often at link time or during module loading.

4. Enable large-file support deliberately

If the program must create or manipulate files larger than 2 GB, add -Duselargefiles when Configure runs. The manual calls this the preferred HP-UX method because Perl is then built with the 64-bit file structures and functions.

$ sh Configure -Duselargefiles

Combine it with the bitness decision when both are required:

$ sh Configure -Duse64bitall -Duselargefiles

This is a build choice, not a switch that can be added to an existing interpreter. Extensions that call file-manipulation functions must be rebuilt against the large-file Perl. If you omit the flag and try to answer the large-file question later, the manual warns that Configure can produce a build that does not compile or behave as expected.

5. Build and test before installing

Let the generated configuration drive the normal Perl build, then run the test suite before writing into a system prefix:

$ make
$ make test
$ ./perl -V:version

A successful make test is the checkpoint here. Compare the reported version and configuration with the choices you recorded. If compilation runs out of data space, the manual says HP-UX's default maxdsiz of 64 MB can be too small for maximum optimisation. Raising it uses SAM, rebuilds the kernel and requires a reboot, so treat that as a planned maintenance action, not an ad hoc compiler fix.

Do not delete the source tree until the installed interpreter and any required extensions have been tested. If the build is wrong, the recovery is to keep the old Perl in service, correct the configuration, and rebuild. There is no useful undo for an overwritten system binary.

6. Keep dynamic extensions in the same ABI

HP-UX shared libraries normally end in .sl on PA-RISC and .so on Itanium. Extensions should normally be built by their own Makefile, but the underlying rules explain the common loader failures:

  • Compile position-independent object files with +z or +Z for HP's compiler, or -fpic or -fPIC for GCC.
  • Link a shared library with ld -b.
  • Include dependent system libraries at link time, or expect unresolved symbols when the extension loads.
  • Keep every object and library in the same PA-RISC or Itanium family and compatible bitness.

An "invalid loader fixup" error usually means that a prebuilt dependency was not compiled as position-independent code. Rebuild the dependency and the extension together. Do not fix an ABI mismatch by renaming .sl to .so, moving libraries between processor families, or adding arbitrary directories to the loader path.

7. Install only after the checks pass

Installing a depot or replacing a shared system Perl changes software used by other applications. Take a maintenance window and preserve the existing interpreter's path and version first. If you are installing HP's packaged Perl from media mounted at /cdrom, the documented shape is:

# swinstall -s /cdrom perl

For a source build, use the installation target and prefix selected during Configure, then verify the exact binary that your service or login will resolve:

# make install
$ command -v perl
$ perl -V:version
$ perl -V:use64bitall
$ perl -V:uselargefiles

The final three values are configuration checks, not proof that every extension is compatible. Run a representative application test and load each important module. If it fails, restore the previous path or package, do not remove libraries at random, and rebuild the extension against the selected Perl.

Done means

  • The machine model, processor family, compiler and target bitness are recorded.
  • Perl was configured with -Duse64bitall and/or -Duselargefiles where the application requires them.
  • make test passed before installation.
  • Extensions and dependent libraries were rebuilt with matching ABI and position-independent code.
  • The installed binary reports the expected version and configuration, and the existing Perl remains recoverable.