http://www.perlmonks.org?node_id=847364

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

Hi monks!

I've got a linux server that through the updating process (not by me!), periodically changes the locations of the perl INC variables so it can't find all of the installed modules. Since I haven't been able to figure it out in the past, I've just reinstalled the packages. At first, it was just 1 or 2, but now I'm having to reinstall 10 or more packages.

Can anyone tell me how to change the global INC variables to include these?

From my research, all I can find is how to include them in the individual scripts. I'm wanting to update the locations for the entire server. Thanks in advance!

Replies are listed 'Best First'.
Re: perl default include library
by almut (Canon) on Jun 30, 2010 at 17:29 UTC

    The default @INC paths are normally hardcoded in the perl binary (or are optionally determined relative to the location of the perl binary, if it had been built with -Duserelocatableinc), so they should not change as long as you call the same perl binary.  There are various ways to add additional directories, such as using PERL5LIB, the -I commandline switch, or in the scripts themselves via use lib, or by directly manipulating @INC.

    Are you sure you're calling the same perl? Are the respective libs still installed after your @INC paths have changed? In what way do they change? What does perl -V show?

      ++

      As a sysadmin and perl user, I've run into similar problems before and they almost always stem from multiple perl binaries installed. You can also get into multiple copies of cpan, and you can get cpan behaving differently depending on what user you log in as. And which of your multiple binaries is cpan executing?

      More concretely, look for /usr/local/bin/perl and /usr/bin/perl. Run "which perl" and "which cpan". Scripts usually have a path in the 1st line, like "#! /usr/bin/perl" so if you have a /usr/local/bin/perl and a /usr/bin/perl and your scripts start with "#! /usr/bin/perl" and your $PATH has /usr/local/bin/ before /usr/bin, you'll be calling the a different binary from the command line than when you execute scripts. E.G. "perl -Mcpan -e shell" would run under /usr/local/bin/perl, while running "cpan" might run under /usr/bin/perl.

      If you're compiling your own perl, make sure you know where it lives and make sure you call it with the full path and make sure cpan calls it as well. It might even be a good idea to put it outside of the usual path (/usr/local/mybin/perl, say), so you know for sure when you call it or the distro installed version. I always keep one and only one perl binary on my systems to avoid this problem.

      Good luck!

      --Pileofrogs

      I have verified that the modules are on the server -- at least I'm still finding the .pm files, just in a different location than the INC locations. When I run the CPAN installer, it's saying these modules are not installed. I've been assuming all along it doesn't think they are installed because it's looking in the wrong location. Am I wrong?

      Currently, it's using perl 5.10 which I'm fairly certain is the same version prior to the server upgrade. I'm not sure which libs have changed because unfortunately, it's not something that I've paid much attention to until it breaks. My bad. Here's the results of perl -v:

      Summary of my perl5 (revision 5 version 10 subversion 0) configuration +: Platform: osname=linux, osvers=2.6.26-2-amd64, archname=i486-linux-gnu-threa +d-multi uname='linux puccini 2.6.26-2-amd64 #1 smp fri aug 14 07:12:04 utc + 2009 i686 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dccc +dlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/ +share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -Dve +ndorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/us +r/local -Dsitelib=/usr/local/share/perl/5.10.0 -Dsitearch=/usr/local/ +lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/ma +n/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man +/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Ua +fs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-O2 + -Duseshrplib -Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=und +ef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict +-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFS +ET_BITS=64', optimize='-O2 -g', cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing + -pipe -I/usr/local/include' ccversion='', gccversion='4.3.2', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=1 +2 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', + lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /usr/lib64 libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=/lib/libc-2.7.so, so=so, useshrplib=true, libperl=libperl.so. +5.10.0 gnulibc_version='2.7' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_ITH +READS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under linux Compiled at Aug 28 2009 22:15:29 @INC: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl

      The system admin said he saw several perl updates at the end of the install of 300+ packages. I'm assuming that whatever packages it installed, it either uninstalled the packages (or at least doesn't show them as installed) or reset some config file somewhere.

      In defense of the sys admin, I barely know what I'm doing and I'm the perl programmer! I'm not expecting him to know more about perl than me.

      So, I just remembered that he likes to make a clone of the server before upgrading. I checked out the clone server and apparently it WAS running a previous version, 5.8.4, so it must have upgraded the perl (sorry, I got it confused with another server).

      Anywhooo...So since the perl was upgraded, am I better off reinstalling the modules, or can I simply point to the existing modules? What is the best practice here?

        As different major versions of Perl (such as 5.8.x vs. 5.10.x) are not binary compatible, you need to reinstall XS modules (those which are not pure Perl).  Pure Perl modules should continue to work, but you might want to check anyway whether there are new versions available (with bugfixes, new features,...).

Re: perl default include library
by rir (Vicar) on Jun 30, 2010 at 17:04 UTC
    Perhaps, setting the environment variable $PERL5LIB would help. PERL5LIB is a PATH-like variable used to locate Perl modules.

    Be well,
    rir

Re: perl default include library
by girarde (Hermit) on Jun 30, 2010 at 17:17 UTC
    I think you have a bigger problem than inability to find Perl modules after the updates: you have a server administrator who runs updates that break important pieces of the system and has no particular concern about it.

      This is why it's recommended to install a separate "application" copy of perl separate from the OS' version that you control separately from whatever vagaries yum or dpkg or port or whathaveyou try to inflict upon you. Disk is cheap and the minimal amount of time it takes is repaid manyfold in the flexibility and insulation from external changes you gain.

      (Written as someone who learned this nugget of wisdom the hard way . . .)

      The cake is a lie.
      The cake is a lie.
      The cake is a lie.