Build a Newer Perl on Solaris Without Touching /usr/bin/perl

Solaris ships its own Perl, and overwriting it is how you turn a routine upgrade into an outage for every system script that shells out to perl. This guide builds a second Perl in its own prefix, leaves the system one alone, and shows you where Solaris-specific builds usually go wrong. It follows the local 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, and operating-system scripts may depend on it. Check the paths before you install anything new:

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

The exact output depends on the host, but the goal is the same everywhere: know which interpreter is the system one and which path the new build will use. Solaris can keep more than one Perl release for compatibility, and the default interpreter does not automatically search an older release's module directories.

• Do not delete or repoint /usr/perl5 or /usr/bin/perl as a shortcut.
• Pick a separate prefix such as /usr/local or /opt/perl for the new build.
• Keep the rollback simple. Remove the new installation only after confirming nothing 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 ahead of anything less suitable:

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, and avoid /usr/ucb/cc entirely. If you use GCC, the manual says to identify it explicitly when running Configure: do not assume that whichever compiler PATH finds first is the one Configure will pick.

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 names the Solaris package that supplied the file. Confirm the missing path and package on that Solaris release before installing anything a build log happens to mention.

3. Extract the source with a Solaris-compatible tar

Use a tar compiled for Solaris. GNU tar compiled for Solaris is fine; a SunOS 4 binary is not, because it can silently mangle a path containing lib/locale during extraction, leaving lib/oldlocale.pm in its place.

$ 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 ones. If you find you used the wrong tar binary, do not carry on and hope the compiler will surface the problem later. Delete the incomplete source directory, extract again with the correct Solaris tar, and repeat the file check.

4. Configure for the compiler you chose

For GCC, the Solaris manual gives this explicit invocation:

$ sh Configure -Dcc=gcc

Accept the normal defaults for a first build unless you have a specific requirement. Perl 5.6.0 and later default to a 32-bit build on Solaris, with large-file and long-long support, which is usually the least surprising choice.

If GCC is set up to use the GNU assembler and linker but you want Solaris's own tools, use this form instead:

$ 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 keep GNU ld, dynamic loading may need the -Wl,-E flags the manual describes: treat that as a toolchain diagnosis, not an excuse to bolt on random linker flags.

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 links that mistake to:

dlopen: stub interception failed

If your extensions need a third-party shared library, point at that library's own directory instead. Do not make this a global shell profile change while testing. Set the variable only for the build or 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 the 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. Nothing here touches the system interpreter:

$ make
$ make test

Use the make that Solaris supplies 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 instead. The manual also warns that op/stat.t can fail on some temporary filesystems, especially when the build lives under /tmp. Move the source tree to a normal filesystem before you call that a Perl defect.

7. Install under a new prefix and verify selection

Only once the build and tests look acceptable should an administrator install the new Perl under the prefix you chose in step 1, using the release's main installation instructions for the exact command. Keep the existing /usr/perl5 tree untouched.

After installing, test the new interpreter by its full path rather than trusting 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 just to make interactive commands shorter: a script with an explicit shebang should keep using the interpreter it was written and tested for.

When Solaris is upgraded, rebuild or reinstall your extra modules for the new Perl. The old module directories are not automatically part of the default interpreter's search path: that is a compatibility boundary, not 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: 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 needs Solaris running in 64-bit mode, and on SPARC the Sun compiler needs the architecture setting getconf reported, commonly -xarch=v9.

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