ActiveState Perl for Win32 seemed to be relocatable. I'm not sure how they did it, or if that applies to their Unix builds. You could check if their HP-UX build is relocatable.

The tacky evile way is to just do the copy and make everyone set PATH and PERLLIB (and ignore the last half of the dirs in @INC in the Can't Find message). But this could cause really icky bugs if someone uses a module in /usr/lib/perl's library but not in yours, after /usr/lib/perl has been updated to a new release and your old clone hasn't.

I've relocated Perl on AIX the less-evil way sucessfully -- copy and patch. The trick is you can only relocate it to a shorter path, so /usr/{bin|lib}/perl doesn't go very far.) However, by building it locally once with a really long original $Config{installprefix}, all is ok. Then Perl's -i.bak and ability to so s/// on binary files can be used, with 'find' or File::Find, to patch the distribution as you install it.

Working from memory -- I'd need three committees approval to cut and paste from $DayJob sourcecode -- the -pi.bak option with @ARGV in slurp mode had a core change something like the following -

s( $Config{installprefix} (/\w+)? )($NewPrefix$1\00)xg;

But: Like the above, But NOT exactly the above, not half as simple. Omit the \00 iff length $NewPrefix  == length $Config{installprefix} . It has to match all the multiple possible sub-dirs. Maybe it's (/[^\0]+)?, but that wouldn't work on Config.pm, I forget. It also actually computed the needed number of padding bytes (of \00) to replace the prior string completely, to maintain the offset (and not leave bumph in the binary). I forget how I avoided null fills when it was .pl/.pm text file or had "" or '' or brackets around it instead of \0 termination.

YMMV. Test before Use. Don't pour hot coffee in lap.

With some care, this will work on both the binary executable and .so's and also the various .pm and .pl scripts distributed, including Config.pm ! (If there's anything else in Config.pm you want to patch at deploy time, have at it - it's text file, no "same size" restriction on patching that.)

My inhouse perl585dist.tgz bundles the script to do this with full Perl install and my recommended lib/site_perl "it should have been standard" module starter set, including the DBI/DBD module that makes all this custom building worthwhile.

(I need to try to build DBD::Oracle next week on a Linux system where I'm _not_ building my own Perl ... this could be fun. At least with RHEL RPM's, there's a good chance the DBI and Perl and C compiler are in sync, so if I perl Makefile.PL something, I should get a makefile that builds something that _will_ link ok. Most of the good modules can be installed from RHEL RPMs, so we're not doing full builds there. Yet.)