Install Perl on Linux Without Replacing the System Version

You will identify the Perl interpreter already in your path, install the distribution package when that is the right fit, and understand when an isolated Perl is safer. You will also have the one special build command documented by perllinux(1) for Sun Studio on Linux. Allow about ten minutes for a package check and verification. A source build needs considerably longer and a compiler toolchain.

This guide follows the installed perllinux(1) manual from Perl 5.38.2, provided by the perl-doc package version 5.38.2-3.2ubuntu0.6 on this machine. The manual describes Perl 5 on Linux rather than a separate executable called perllinux.

1. Check the Perl that is already selected

Start without changing anything. These commands are ordinary, unprivileged checks:

$ command -v perl
/usr/bin/perl
$ perl -e 'print "$^V\n"'
v5.38.2
$ perl -V:version
version='5.38.2';

The path is the executable the shell will run. The version comes from that interpreter, not from a package name you happen to remember. If command -v perl prints nothing, Perl is not currently available through your PATH; do not guess a path and do not replace a file in /usr/bin by hand.

2. Use the distribution package for the system Perl

For a normal system installation, use your distribution's package manager. The manual gives these examples:

$ sudo apt-get install perl
$ sudo dnf install perl

Run only the command belonging to your distribution. These commands require elevated privileges because they change the system package database and install files for all users. Read the package manager's transaction before accepting it. Do not run both examples, and do not copy an apt-get command onto a Fedora-family system or a dnf command onto Debian or Ubuntu.

After the transaction finishes, repeat the checks from step 1:

$ command -v perl
/usr/bin/perl
$ perl -V:version
version='5.38.2';

Your version may differ. The useful result is that the interpreter exists at the expected path and reports a version that the package manager installed.

3. Do not overwrite system Perl for an application experiment

The manual warns that changing the system Perl is not always recommended. System utilities and distribution packages can depend on the version and modules supplied by the operating system. Replacing /usr/bin/perl manually can therefore break tools that are unrelated to your application.

If you need another Perl for development or for CPAN frontends, use an isolated tool such as perlbrew. The manual points to perlbrew for this purpose. Follow its current installation instructions and keep its interpreter selection confined to the shell or project that needs it. Verify the result with the same two checks:

$ command -v perl
/path/to/isolated/perl
$ perl -V:version
version='X.Y.Z';

The path and version above are placeholders, not expected literal output. Replace them only after the isolated installation has completed. In a fresh shell, check again before assuming that the isolated interpreter is still selected.

4. Choose a compiler build only when you need one

The manual says Perl should build on Linux with mainstream GCC and clang compilers, following the usual Perl build instructions. That route is appropriate when you need a source build or a version unavailable as a distribution package. It is not a reason to rebuild the system interpreter during routine package maintenance.

A source build also needs a writable build directory and the normal compiler, linker and supporting development packages. Those prerequisites vary by distribution, so install them through the distribution documentation rather than treating a partial build error as a Perl runtime problem. Keep the source-build directory separate from /usr/bin and test the resulting interpreter by its explicit path before changing your shell configuration.

5. Apply the Sun Studio exception only to that compiler

The manual includes an experimental case for Sun Studio compilers on Linux. It says to complete the normal Configure step, then invoke make with LDLOADLIBS=-lc:

$ LDLOADLIBS=-lc make

LDLOADLIBS is an environment variable used by the linker for Perl extension modules and glibc. This is not a general Linux fix for a failed GCC or clang build. Use it only when you have deliberately chosen Sun Studio and the build reaches the documented situation.

The manual describes this support as experimental and notes that the last stable Sun Studio release was in 2017. Do not add LDLOADLIBS=-lc to every build, export it globally, or use it to mask an unrelated compiler or dependency error.

6. Recover without losing the working interpreter

If a package install or source build leaves you unsure which Perl is active, stop changing files and rerun:

$ command -v perl
$ perl -V:version

Compare the path with the one recorded in step 1. If a user-local tool changed your shell selection, start a new shell or use that tool's documented way to select its interpreter. If a system package transaction failed, use the package manager's own repair and transaction commands for your distribution. Do not delete /usr/bin/perl as a repair step.

If you have changed shell startup files to select an isolated Perl, undo only the lines you added, then open a new shell and repeat the checks. Do not remove an entire startup file: it may contain unrelated access, proxy or development settings.