Build a 64-bit Perl 5.38 Port for IRIX Without Guessing

You will finish with a compiler configuration chosen for the IRIX CPU and compiler you actually have, plus a small set of checks for the resulting Perl build. The local perlirix(1) page is a porting note: it is documentation for compiling Perl on IRIX, not a command named perlirix that runs Perl scripts.

Allow at least thirty minutes for configuration and a longer build on vintage hardware. You need an IRIX source tree containing Configure, a supported IRIX C compiler or GCC, and a writable build directory. The installed reference here comes from the perl-doc 5.38.2 package and documents Perl 5.8-era IRIX details, so treat old release notes and test results as version-specific evidence rather than a promise for every Perl release.

1. Confirm that you are building on the right host

Run these ordinary, read-only checks on the IRIX machine:

$ uname -a
$ cc -version
$ test -f Configure && echo "Configure is present"
$ test -f hints/irix_6.sh && echo "IRIX hints are present"

The compiler check matters. The manual says -n32 is only worth using with IRIX 7.1 or later compilers, and recommends cc -version to check. If cc is missing, stop and choose an installed compiler deliberately. Do not substitute flags from a different Unix port.

2. Keep the source tree recoverable

Make a separate build copy or a backup before experimenting with compiler flags. Configure writes build configuration into the source tree, and a failed experiment can leave generated files behind.

$ cp -pR perl-source perl-source.before-irix-build
$ cd perl-source

Replace perl-source with your real directory. This copy command changes storage but does not alter the original tree. Check that the copy exists before proceeding:

$ test -f perl.c && test -x Configure && echo "source copy looks usable"

If the copy is incomplete, recover by removing only that named copy and making a fresh copy from the original. Do not delete the original source directory as a shortcut.

3. Choose the 32-bit configuration

For a 32-bit Perl, use the IRIX compiler's -n32 mode:

$ sh Configure -Dcc='cc -n32'

The manual describes this as the default build mode and warns against relying on -n32 with compilers older than IRIX 7.1. When Configure asks questions, record its choices and keep the default allocator. In particular, do not enable Perl's own malloc on IRIX. The porting notes associate that choice with mysterious failures, especially in 64-bit configurations.

After Configure finishes, inspect the generated summary before compiling. The exact text varies by Perl release, so look for the selected compiler and the absence of a Perl malloc request:

$ grep -E '^(cc|use64bit|usemymalloc)' config.sh 2>/dev/null || true

A missing match is a reason to inspect config.sh manually, not a reason to guess that the setting was accepted.

4. Choose a 64-bit configuration

Use the following configuration only when the target is suitable for it:

$ sh Configure -Dcc='cc -64' -Duse64bitint

The documented cc -64 route requires a 64-bit MIPS CPU, such as an R8000 or R10000. The practical result is 64-bit integer support in a 64-bit compiler build. The manual also lists -Duse64bitall, but says it makes no difference here because cc -64 already selects the relevant model. Do not add it merely to make the command look more complete.

If you have a 32-bit compiler environment but need 64-bit integers, the documented alternative is:

$ sh Configure -Dcc='cc -n32' -Duse64bitint

With GCC, the porting note gives this shorter form:

$ sh Configure -Dcc=gcc -Duse64bitint

Configure is expected to probe suitable settings in that case. It does not turn an unsuitable CPU or system library into a supported 64-bit target.

5. Build and handle compiler failures narrowly

Build with the normal project target after reviewing Configure's summary:

$ make
$ ./perl -v

Success means the build completes and the new binary prints its version. Check the binary rather than relying on the host's installed Perl:

$ file ./perl
$ ./perl -V:use64bitint -V:use64bitall

The displayed values should match the configuration you intended. Exact file wording is platform-specific, so the useful distinction is whether the binary is the expected IRIX executable and whether the Perl configuration reports the requested integer model.

If an IRIX compiler crashes while compiling perl.c, the manual calls out some cc versions, including 7.3.1.1m, and an interaction with -OPT:fast_io=ON. First remove that optimisation from the flags. If the failure remains, adjust one optimisation setting at a time, such as reducing -O3 to -O2. Keep each attempt separately recorded so you can return to the last known configuration.

6. Treat linker and test warnings as evidence

A complaint about so_locations is a linker configuration problem. Inspect hints/irix_6.sh for its lddflags guidance and apply only the adjustment that matches your IRIX release. Do not copy linker flags from an unrelated host.

IRIX 5.3 may print unresolved libm.so warnings and a toke.c optimisation warning. The reference says those warnings are expected and cannot be silenced cleanly on that release. That does not make every warning harmless: stop for a hard linker error, a failed build, or a runtime crash.

For IRIX 5.3 with Perl 5.8.1, the notes record failures in selected tests and attribute them to suspected compiler or maths-library issues. Those historical results do not validate a current build. Run the release's test suite, save the complete output, and investigate failures before deploying the binary. Never enable threaded Perl casually on IRIX 6.2: the reference warns that patch 2401 is required because an older kernel bug could panic the machine. IRIX 6.3 and later are described as safe from that specific issue.