Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: perl default include library

by almut (Canon)
on Jun 30, 2010 at 17:29 UTC ( #847368=note: print w/replies, xml ) Need Help??


in reply to perl default include library

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?

Replies are listed 'Best First'.
Re^2: perl default include library
by pileofrogs (Priest) on Jun 30, 2010 at 22:49 UTC

    ++

    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

Re^2: perl default include library
by ksublondie (Friar) on Jun 30, 2010 at 18:06 UTC
    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.

Re^2: perl default include library
by ksublondie (Friar) on Jun 30, 2010 at 21:04 UTC
    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,...).

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (3)
As of 2021-06-19 16:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What does the "s" stand for in "perls"? (Whence perls)












    Results (93 votes). Check out past polls.

    Notices?