Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

managing a single Perl installation across slightly different Linux OSs

by jae_63 (Beadle)
on Jan 02, 2014 at 19:36 UTC ( #1069012=perlquestion: print w/replies, xml ) Need Help??

jae_63 has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I need to install and manage a single fairly modern version of Perl across roughly 10 servers plus a cluster, which run different version of Redhat and its kin.

I'm not root on these systems, but the sysadmins will do a few things for me upon request. However they won't let me overwrite the default Perl's on these systems, since they don't want to destabilize other aspects of the systems.

The default Perl on seven systems running "Scientific Linux SL release 5.3 (Boron)" is 5.8.8. There's also a system running "Red Hat Enterprise Linux Server release 5.3 (Tikanga)" which runs 5.8.8. There are two other servers plus hundreds of cluster nodes which run "Scientific Linux release 6.3 (Carbon)" and Perl 5.10.1.

I am open to standardizing upon any reasonably recent Perl version, such as 5.10.1 or 5.16.3.

I would like to install a parallel (non-default) single version of Perl to work on all of these systems. I have considered perlbrew and local::lib, but for now am instead following the advice of Brian D. Foy who suggests careful construction of Perl from source using the "Configure" script, e.g.: ./Configure -des -Dprefix=/usr/local/perls/perl-5.16.3 Stackoverflow link while avoiding the use of the PERL5LIB environment variable.

Building Perl doesn't take that long, but fighting through the installation of all the CPAN modules which are prerequisites for our in-house modules takes several hours. So when you try different variations of this over-and-over-again, it seems like a never-ending battle.

------------------------------

Based upon the advice of a local sysadmin, I decided to build my Perl on the oldest relevant O.S., and hope that backwards-compatability will permit everything to run on newer systems. Similarly I'm not attempting any static linking of libraries. In this example, I built Perl 5.16.3 on SL 5.3.

In addition to some challenges involving AUTOLOAD, the other major barrier are dynamic libraries from XS code, such as the following in /usr/local/perl5/perls/perl-5.16.3/lib/site_perl/5.16.3:

./x86_64-linux/auto/DBD/Pg/Pg.so ./x86_64-linux/auto/DBD/mysql/mysql.so ./x86_64-linux/auto/List/MoreUtils/MoreUtils.so ./x86_64-linux/auto/Params/Util/Util.so ./x86_64-linux/auto/Params/Validate/XS/XS.so ./x86_64-linux/auto/Term/ReadKey/ReadKey.so ./x86_64-linux/auto/DateTime/DateTime.so ./x86_64-linux/auto/GD/GD.so ./x86_64-linux/auto/Clone/Clone.so

For example, one (critical) local Perl script runs OK on the older SL 5.3 systems. But on an SL 6.3 system it yields the following error:

install_driver(Pg) failed: Can't load '/usr/local/perl5/perls/perl-5.16.3/lib/site_perl/5.16.3/x86_64-linux/auto/DBD/Pg/Pg.so' for module DBD::Pg: libpq.so.4: cannot open shared object file: No such file or directory at /usr/local/perl5/perls/perl-5.16.3/lib/5.16.3/x86_64-linux/DynaLoader.pm line 190, <DATA> line 751. at (eval 390) line 3. Compilation failed in require at (eval 390) line 3, <DATA> line 751. Perhaps a required shared library or dll isn't installed where expected at /usr/local/perl5/perls/perl-5.16.3/lib/site_perl/5.16.3/Rose/DB.pm line 965.

There's no libpq.so.4 on the newer system, only /usr/lib64/libpq.so.5.

I'd love to know how to address this libpq problem in particular, but it seems like just the tip of the iceberg, and that I need to modify my approach in some fashion. I did spend some time with perlbrew, but run into similar problems there.

Thanks in advance for your advice

  • Comment on managing a single Perl installation across slightly different Linux OSs

Replies are listed 'Best First'.
Re: managing a single Perl installation across slightly different Linux OSs
by syphilis (Bishop) on Jan 02, 2014 at 23:42 UTC
    I think I would build and install perl separately on each of the 10 servers (using same configure specs), then write a script that installs all required modules, and then run that script on each of the 10 servers.

    That should avoid the type of problem you're experiencing with DBD::Pg. If you really want to just build once and then distribute, the only solutions to your DBD::Pg problem I can think of are:
    1) Build DBD::Pg (and the others) against static libs;
    2) Place a copy of libpq.so.4 (and the other shared libs) in the same directory as the perl executable.

    Not sure that either of those two last options will scale terribly well. The second solution also assumes that the perl executable will be in the path on all machines.

    Cheers,
    Rob
Re: managing a single Perl installation across slightly different Linux OSs
by dasgar (Priest) on Jan 03, 2014 at 05:55 UTC
Re: managing a single Perl installation across slightly different Linux OSs
by Anonymous Monk on Jan 03, 2014 at 04:06 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1069012]
Approved by Paladin
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (4)
As of 2020-12-04 05:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How often do you use taint mode?





    Results (58 votes). Check out past polls.

    Notices?