The general strategy would be to compile Perl on a machine that's compatible with the target systems, and install it into the appropriate directory, i.e. the one that you want to have it installed on the target systems. This is because a Perl 5.8 installation is not 'relocatable' (as opposed to 5.10) — the installation path is hardcoded in the binary, so it will find its libs via the default @INC. Also, it's probably easiest to use a directory layout where everything (binary, libs (modules), docs) is below one toplevel directory. See the INSTALL file that comes with the source for the details.

Then, create a tarball (or whatever package format you're using for your app) of the entire directory tree into which you've installed Perl, and bundle that with your application. That's it, essentially.

The recent node Re: putting perl and modules in your source code repository describes how I build a custom Perl distribution that's distributed with our product.

To defeat the lack of relocatability of perl 5.8.x, mentioned by almut, I ask the user to set an environment variable (YOUR_PRODUCT_HOME, say) and unpack our perl distribution in a well-known sub-directory underneath $YOUR_PRODUCT_HOME. With that done, our custom perl is invoked via a shell wrapper, for example for perl 5.8.6 on solaris the shell wrapper is:

#!/bin/sh
if [ -z "$YOUR_PRODUCT_HOME" ]; then
   echo "error: YOUR_PRODUCT_HOME environment variable is not set." 1>
+&2
   exit 1
fi
$YOUR_PRODUCT_HOME/perl/bin/perl -I"$YOUR_PRODUCT_HOME/perl/lib/5.8.6/
+sun4-solaris" -I"$YOUR_PRODUCT_HOME/perl/lib/5.8.6" -I"$YOUR_PRODUCT_
+HOME/perl/lib/site_perl/5.8.6/sun4-solaris" -I"$YOUR_PRODUCT_HOME/per
+l/lib/site_perl/5.8.6" -I"$YOUR_PRODUCT_HOME/perl/lib/site_perl" "$@"
[download]

In our next release, I'll upgrade perl to 5.10.x and look forward to eliminating the ugly shell wrapper by taking advantage of its relocation capabilities.

Update: Warning: Note that the shell wrapper above is just a dirty hack that works for me in my environment where the customer just uses the distributed perl as is, and does not install any new modules, for example; it is not a 100% sound relocatable Perl. For that, you'll need perl 5.10.x. To relocate perl 5.8.x more soundly, you might further edit Config.pm and study in detail how perl 5.10.x does it (IIRC, ActiveState has done a relocatable Unix perl 5.8.x for some platforms).

At my place of work we have a bunch of Solaris boxes, and we leave the /usr/bin/perl alone and install our own Perl under /work/system/bin. All of the Perl modules we use are then installed under that, and any of our shebang lines refer to our Perl.

We use /opt for that purpose, as suggested by Solaris filesystem(5):

/opt  Root of a subtree for add-on application packages.
[download]

Update To expand on that, we build our own perl and install it under /opt/perl/5.x.x with judicious symlinks so:

/opt/local/bin/perl -> ../../perl/5.8.8/bin/perl
/opt/local/perl/bin -> ../../perl/5.8.8/bin
/opt/local/perl/man -> ../../perl/5.8.8/man
[download]

We use #!/opt/local/bin/perl as the shebang line in our Perl programs, and add /opt/local/perl/bin to PATH and /opt/local/perl/man to MANPATH. We can then upgrade perl simply by tweaking those three symlinks. Worked fine for the last upgrade.