Build Perl on Tru64 Without Mixing Toolchains

You will get a disciplined build plan for Perl 5 on Tru64: select one compiler and linker toolchain, give Configure enough process space, preserve Tru64's built-in 64-bit and large-file behaviour, and separate genuine failures from harmless compiler warnings. This is a build guide, not a way to run the Tru64-specific command on Linux. The installed reference here is perl-doc version 5.38.2-3.2ubuntu0.6; its perltru64(1) page is generated from Perl 5.38.2 and describes historical Tru64 support, so check the source tree you are actually building as well.

Allow 30 to 60 minutes for a prepared source tree, longer on an old Tru64 host. You need a Tru64 4.0 or newer system for reliable threaded builds, the Perl source distribution, a writable build area, and either the native C toolchain or a compatible GNU toolchain. Do not run the build as root. Install the final files with the account and method used by your site's software policy.

1. Check the host and choose one toolchain

Start by recording the operating-system release and locating the tools that will be used. The native C compiler is the recommended choice because it normally produces faster and more correct Perl binaries on Tru64. If you use GCC, the manual warns that releases older than 2.95.3 are known to produce broken builds, including core dumps in SDBM, regular-expression and Storable tests.

$ uname -a
$ which cc
$ which gcc
$ which ar
$ which ld

Do not treat the presence of gcc as a reason to use it. In particular, Tru64 V5 headers reject some GCC versions when building threaded Perl. Select either the native compiler and native ar/ld, or a consistently installed GNU set. Mixing them can produce read_cur_obj_info: bad file magic number later.

2. Give Configure enough process space

Perl consumes substantial memory while compiling. toke.c is a known optimisation hotspot, and the Unicode table build can also hit the process data limit. Tru64 commonly allows a one-gigabyte data section, but local limits may be lower.

$ ulimit -d
$ ulimit -a

If Configure reports a low process limit, follow its advice for the current shell, for example:

$ ulimit -d 262144

The value is a shell limit in kilobytes and may be subject to the host's maximum limit. If the command is rejected, ask the system administrator to review the account or login configuration. Do not keep retrying a build that is failing from resource limits: it can leave misleading partial objects behind.

3. Clear the shell variable that breaks Configure

Before running Configure, check BIN_SH:

$ echo "$BIN_SH"
$ unset BIN_SH

When BIN_SH=xpg4, /bin/sh delegates to a Korn shell. The Tru64 Perl documentation records a failure in which Configure stops near the threaded-build question with a syntax error mentioning config.sh. Unsetting the variable in this shell prevents that delegation. It does not change the system shell or other users' sessions.

If you already ran Configure with the bad setting, remove the generated configuration as directed by the source release, or unpack a fresh source tree. The safe principle is to rerun Configure from a clean state after the environment is corrected.

4. Configure the build deliberately

Run the source tree's Configure script with the options your deployment needs. Tru64 already supplies 64-bit integers and 64-bit pointers, so do not add -Duse64bitint or -Duse64bitall merely to obtain those properties. It also supports files larger than 2 GiB automatically; -Duselargefiles is unnecessary, although the manual says it is harmless.

$ ./Configure -des
$ make

-des is a normal Perl Configure shortcut for a largely automated build. Review the questions and the generated configuration for your release rather than copying an old config.sh. If you need threads, use the documented Perl 5.8-era model option:

$ ./Configure -des -Duseithreads

Threaded Perl is documented as working only from Tru64 4.0 onwards. On Tru64 V5, prefer the native C compiler for this build because the system pthread.h checks whether the compiler is supported.

5. Run the tests and classify warnings

Test before installing:

$ make test

On Tru64, the comp/cpp test is skipped because it cannot be exercised before Perl is installed. That skip is documented behaviour, not by itself a failed build. You may also see native compiler warnings about floating-point overflow while compiling numeric.c or the POSIX extension. The manual describes those warnings as benign; later compiler releases may not print them.

A static build can fail the ext/ODBM_File/odbm test because of a Tru64 static libdbm bug. If you do not need that extension, avoid a static build. The more capable NDBM_File or DB_File may be better fits, subject to the libraries you intend to support.

6. Fix library and operating-system mismatches

DB_File failures often mean that Configure found headers and libraries from different Berkeley DB generations. In particular, mixing DB v2 libraries with the Tru64-supplied DB 1.85 headers is unsafe. Inspect /usr/local/include, /usr/local/lib, and any -Dlocincpth or -Dloclibpth settings before changing them.

$ ls -ld /usr/local/include /usr/local/lib
$ echo "$LD_LIBRARY_PATH"

If you intentionally use a newer Berkeley DB, configure both include and library directories together, then set LD_LIBRARY_PATH for the test process as the manual describes:

$ ./Configure -des -Dlocincpth=/some/include -Dloclibpth=/some/lib
$ LD_LIBRARY_PATH=/some/lib make test

Replace the example paths only with directories belonging to the same DB installation. If Perl later fails with an unresolved sockatmark symbol in the IO extension, the documented remedies are to rebuild for Tru64 4.0D or upgrade that host to at least 4.0F. Do not hide the error by removing arbitrary libraries from the system.