Build a Separate Perl for Solaris Without Breaking the System Perl

You will finish with a Solaris build plan that keeps the operating system's Perl intact, selects the right compiler tools, and gives you a useful diagnosis when Configure or the test suite fails. The local reference is the perlsolaris manual from Perl 5.38.2, generated on 14 September 2026. Some of its examples describe older Solaris releases, so version-specific limits are called out rather than presented as current defaults.

Allow 30 to 60 minutes for a normal source build, plus time to obtain a compiler and Solaris development packages. You need a Solaris host, Perl source, an ANSI C compiler, the development tools and enough space for a source tree. Building in a private directory is ordinary user work. Installing into a shared prefix needs an administrator.

1. Inspect the Perl that Solaris already owns

On Solaris 8 and later, the system Perl is normally under /usr/perl5, with /usr/bin/perl pointing into it. It may be used by operating-system scripts. Check the paths before choosing a new installation:

$ type -a perl
$ ls -l /usr/bin/perl
$ /usr/bin/perl -V:version -V:osname -V:osvers

The exact output depends on the host. The important result is that you know which interpreter is the system one and which path you will use for the new build. Solaris can retain more than one Perl release for compatibility, and the default interpreter is not necessarily configured to search the older release's module directories.

Do not delete or repoint /usr/perl5 or /usr/bin/perl as a shortcut. If you need a newer Perl, choose a different prefix such as /usr/local or /opt/perl. A separate prefix gives you an uncomplicated rollback: remove that new installation only after checking that no service or script depends on it.

2. Prepare the Solaris build environment

Perl needs an ANSI C compiler. The Solaris-specific tools ar, as, ld and make are commonly in /usr/ccs/bin, so put that directory in front of less suitable alternatives:

PATH=/usr/ccs/bin:$PATH
export PATH
command -v ar
command -v make
command -v cc

If you use Sun's compiler, put its directory, commonly /opt/SUNWspro/bin, before /usr/ucb. Avoid /usr/ucb/cc. If you use GCC, the manual says to identify it explicitly when running Configure; do not assume that the compiler found first in PATH is the one Configure will select.

Solaris development installations also need the relevant tools, headers and libraries. If a header or executable is missing, an administrator can search the package contents database:

# grep /my/missing/file /var/sadm/install/contents

The final field identifies the Solaris package that supplied the file. The leading # marks an administrator command. Do not install arbitrary packages just because a build log mentions a name; first confirm the missing path and package on that Solaris release.

3. Extract the source with a Solaris-compatible tar

Use a tar compiled for Solaris. GNU tar compiled for Solaris is acceptable; a SunOS 4 binary is not. SunOS 4 binaries can silently transform a path containing lib/locale while extracting, leaving lib/oldlocale.pm instead.

$ mkdir -p /path/to/build
$ cd /path/to/build
$ tar xzf /path/to/perl-5.38.2.tar.gz
$ cd perl-5.38.2
$ test -f Configure && printf '%s\n' 'source tree ready'

Replace both placeholder paths with real paths. If you used the wrong tar binary, do not continue and hope the compiler will expose the problem. Remove that incomplete source directory, extract again with the correct Solaris tar, and then repeat the file check.

4. Configure for the compiler you chose

For GCC, the Solaris manual gives this explicit invocation:

$ sh Configure -Dcc=gcc

For a first build, accept the normal defaults unless you have a specific requirement. Perl 5.6.0 and later are described as 32-bit builds by default on Solaris, with large-file and long-long support. That default is often the least surprising choice.

If GCC is configured to use GNU assembler and linker but you want Solaris's tools instead, the manual gives this form:

$ sh Configure -Dcc='gcc -B/usr/ccs/bin/'

The trailing slash is required. Configure may print a harmless warning that the prefix was never used. If you deliberately use GNU ld, dynamic loading may require the -Wl,-E flags described by the manual; treat that as a toolchain diagnosis, not as a reason to add random linker flags to a working build.

5. Keep the runtime library path clean

Check LD_LIBRARY_PATH before compiling. It must not include /lib or /usr/lib. On Solaris those paths can be symlinks into the standard library location, and the manual associates them with:

dlopen: stub interception failed

If your extensions need a third-party shared library, include that library's directory instead. Do not make a global shell profile change while testing. Set the variable only for the build or the command that needs it, and record the old value first:

old_ld_library_path=${LD_LIBRARY_PATH-}
printf 'LD_LIBRARY_PATH=%s\n' "${old_ld_library_path:-<unset>}"
export LD_LIBRARY_PATH=/path/to/third-party/lib

To undo that temporary setting in the current shell, run unset LD_LIBRARY_PATH, or restore the saved value if it was non-empty. Leaving a broad library path in a service environment can make unrelated programs load the wrong libraries.

6. Build and test without installing

Run the build from the source directory first. This does not replace the system interpreter:

$ make
$ make test

Use the make supplied by Solaris for the ordinary build. If you use Sun's parallel dmake and tests fail in ways that look like ordering problems, rerun with -m serial or use /usr/ccs/bin/make. The manual also warns that a test involving op/stat.t can fail on some temporary filesystems, especially when the build is under /tmp. Move the source tree to a normal filesystem before treating that failure as a Perl defect.

7. Install under a new prefix and verify selection

Only after the build and tests are acceptable should an administrator install the new Perl under the prefix chosen in step 1. Use the Perl release's main installation instructions for the exact install command and prefix setting. Keep the existing /usr/perl5 tree untouched.

After installation, test the new interpreter by its full path rather than relying on PATH:

$ /opt/perl/bin/perl -V:version -V:prefix
$ /opt/perl/bin/perl -e 'print "new perl works\n"'

If that works, add /opt/perl/bin to the intended users' PATH in a controlled shell or service configuration. Do not repoint /usr/bin/perl merely to make interactive commands shorter. A script with an explicit shebang should continue to use the interpreter it was written and tested for.

When Solaris is upgraded, rebuild or reinstall extra modules for the new Perl version. The old module directories are not automatically part of the default interpreter's search path, which is a compatibility boundary rather than a missing-file bug.

8. Choose 32-bit or 64-bit deliberately

Ask Solaris what application modes the host supports:

$ isainfo -v
$ getconf -a | grep v9

The manual's practical rule is to stay with the default 32-bit Perl unless you need more than about 4 GB of address space or more than 255 open file descriptors. A 32-bit Perl can still have large-file and 64-bit integer support. A 64-bit application also requires Solaris to be running in 64-bit mode, and on SPARC the Sun compiler needs the architecture setting reported by getconf, commonly -xarch=v9.

This is a build decision, not a post-install switch. If a module depends on Solaris structures such as off_t, read its Solaris compatibility notes before changing the data model. The manual specifically calls out older versions of Proc::ProcessTable and BSD::Resource as large-file-sensitive.