Can I move a Perl installation from one computer to another computer?

Question

I am trying to set up an application dependant on few Perl modules, but the server I am installing to, does not have Internet connection. I read about offline module installs via ppd files, however I would have to resolve all the dependencies one by one.. All the more tedious considering I don't have direct internet connection.

I am hoping to find a solution, where I install ActivePerl on my PC and install all the libraries that I want and then copy paste the directories to my server. If it is just a matter of fixing some environment variables, that would be fine. Just want to know the definitive list of variables to modify. Not sure whether it is mandatory to install the perl libraries on the computer in which it is intended to run? (One is 32 bit platform and other one is 64 bit, but the server is already running various 32 bit applications so I hope it is not a major problem) For best compatibility, I plan to install ActivePerl on both the systems and merge the library directories to be identical.

Answer 1

The answer was on Perl FAQ, my bad didn't go through it properly.

I copied the perl binary from one machine to another, but scripts don't work.
That's probably because you forgot libraries, or library paths differ.
You really should build the whole distribution on the machine it will
eventually live on, and then type "make install". Most other approaches
are doomed to failure.

One simple way to check that things are in the right place is to print
out the hard-coded @INC that perl looks through for libraries:

    % perl -le 'print for @INC'

If this command lists any paths that don't exist on your system, then
you may need to move the appropriate libraries to these locations, or
create symbolic links, aliases, or shortcuts appropriately. @INC is also
printed as part of the output of

    % perl -V

You might also want to check out "How do I keep my own module/library
directory?" in perlfaq8.

Answer 2

From this link

Occasionally, you will not be able to use any of the methods to install modules. This may be the case if you are a particularly under-privileged user - perhaps you are renting web space on a server, where you are not given rights to do anything.

It is possible, for some modules, to install the module without compiling anything, and so you can just drop the file in place and have it work. Without going into a lot of the detail, some Perl modules contain a portion written in some other language (such as C or C++) and some are written in just in Perl. It is the latter type that this method will work for. How will you know? Well, if there are no files called something.c and something.h in the package, chances are that it is a module that contains only Perl code.

In these cases, you can just unpack the file, and then copy just the *.pm files to a directory from which you will run the modules. Two examples of this should suffice to illustrate how this is done.

IniConf.pm is a wonderful little module that allows you to read configuration information out of a .ini-style config file. IniConf.pm is written only in Perl, and has no C portion. When you unpack the .tar.gz file that you got from CPAN, you will find several files in there, and one of them is called IniConf.pm. This is the only file that you are actually interested in. Copy that file to the directory where you have the Perl programs that will be using this module. You can then use the module as you would if it was installed ``correctly,'' with just the line:

    use IniConf;

Time::CTime is another very handy module that lets you print times in any format that strikes your fancy. It is written just in Perl, without a C component. You will install it just the same way as you did with IniConf, except that the file, called CTime.pm, must be placed in a subdirectory called Time. The colons, as well as indicating an organization of modules, also indicates a directory structure on your file system.