Question

Hi,

I'm having a problem with the @INC variable. In fact, i had problems with an update of perl (i was using perl 5.6 previously and decided to update to 5.8 while i was updating my twiki version... it truned to be a problem so i reinstalled the version 5.6). Coz now, perl is working with no problem and i had neither any problem with twiki. Until i decided to install a new plugin which requires CPAN modules. I installed them without a problem but i can't activate my plugin because it can't find the correct perl module : TWiki::Plugins::MailReminderPlugin could not be loaded. Errors were: Can't locate Date/Calc.pm in @INC

I checked the @INC in TWiki and in perl (from the shell) and it appears that it's not the same : TWiki still points on 5.8 folders and perl is using the 5.6 In the 5.6 i can see my modules correctly installed. I tried to trick twiki in adding the correct folders thanks to LocalLib.cfg (to point to the folders contained in the @INC of 5.6 version), but it still doesn't work... Any idea ?

Environment

-- GuillaumeBardy - 20 Aug 2007

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

Oh heck, you are probably in a bit of a mess. There are soooo many things that might have gone wrong. Upgrading perl is one thing, downgrading it again is a lot harder. There are various references (use Google) to running two perl versions in parallel, I would suggest this is your best approach. But I would strongly recommend you not to try, but to upgrade to 5.8 instead and work out / fix why it failed.

-- CrawfordCurrie - 20 Aug 2007

But still my problem is also that the @INC of TWiki is not pointing to my current version of perl... so even if i upgrade it, i'm not sure it'd change anything. What i'd really like to know is : how to modify the @INC in Twiki ?

-- GuillaumeBardy - 21 Aug 2007

TWiki modifies the @INC in bin/setlib.cfg by adding to it what is set in bin/LocalLib.cfg.

So you could hack it to force it to use the libs you think are right.

however this is not where you want to be changing perl's internal library paths from underneath it.

What you have is a very misconfigured perl system, so using TWiki's cfg's to fudge it, will only result in some hidden mess-ups later.

If you do hack it, you will be changing perl lib directories midway through the execution of perl, and probably will cause cpan bite you.

-- SvenDowideit - 21 Aug 2007

Actually i have no idea what is good or not, i don't even know if my 5.8 was correctly installed. I only know that the libs are in usr/lib and that my shell is using perl 5.6.2 which libs are in usr/local/lib... Is it something a bit normal ? Am i supposed to have 2 folders with libs (even from the same versions of Perl) ? I do believe that Twiki should point to my 5.6 version. From my understanding, you don't modify the @INC in setlib or even in LocalLib, you can only add some other folders. My question is : how Twiki can find a different @INC with the one i find from the shell ? Environment difference ? How can i change that ?

-- GuillaumeBardy - 21 Aug 2007

Ok, i found out some stuff : i really have two versions actually installed. The 5.6 is accessible by calling perl the other one by calling perl5.8.8 So i could install my modules and find a way to go. Still, i'd like to know where twiki finds the path of @INC

-- GuillaumeBardy - 21 Aug 2007

TWiki does not find @INC. it is told @INC by perl.

-- SvenDowideit - 22 Aug 2007

Told by perl... But what if there is more than one version of perl installed ? And told by perl, what kind of process is it ? How can they find each other ? env variable ? conf file ?

-- GuillaumeBardy - 23 Aug 2007

The "original" paths in @INC are compiled into the executable, you normally don't see this process if you install Perl as a Linux package. You can examine the paths with one-liner commands like these:

perl -V
perl5.8.8 -V

    /etc/perl
    /usr/local/lib/perl/5.8.4
    /usr/local/share/perl/5.8.4
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.8
    /usr/share/perl/5.8
    /usr/local/lib/site_perl
    .

Actually, you can do anything to @INC in TWiki's bin/LocalLib.cfg, and Perl will pick it up from there on. Usually one just adds new directories by prepending to the list. This is basically the same as if you start perl with a -I switch or add directories with Perl's use lib pragma.

None of TWiki's libraries should be installed in version specific directories (well, maybe Crawford's XS search is an exception, but it isn't installed per default).

Another thing to keep in mind when examining Perl paths and @INC is the PATH environment your shell processes. TWiki explicitly invokes /usr/bin/perl. Now say which perl to your computer. Maybe it is /usr/local/bin/perl? There you are. Either of those might be just a symlink to a "versioned" perl, like in the following example from Solaris:

$ ls -l /usr/bin/perl
lrwxrwxrwx   1 root     root          23 Apr  8  2005 /usr/bin/perl -> ../perl5/5.8.4/bin/perl

Running different versions of Perl on the same machine is always difficult, especially if they have installed with different methods (e.g. package vs. own compilation). So, what are the options?

1. If installing Perl modules for TWiki, explicitly use TWiki's version of perl. You can't enforce that if installing modules as Linux packages, you need to do it the hard way:

        /usr/bin/perl -MCPAN -e shell
        cpan> install Date::Calc
        

2. If you want TWiki to use the same perl than you do, you could adjust the first line of TWiki's programs in the bin directory to explicitly call /usr/local/bin/perl instead of /usr/bin/perl (if that's what which perl gives you). But this is a mess and calls for problems with TWiki updates.
3. Check which of the Perl versions your Fedora has as a package (I'd guess some 5.8), get rid of all other versions of Perl on your computer, make a clean re-install of the Fedora package and hack through all remaining problems. That's what I would do, but I am not a Fedora expert...

-- HaraldJoerg - 23 Aug 2007

Thanx Harald, that's the kind of answer i was looking for. Thx for giving some of your time to give a clear and complete answer. Anyway, i'm working on a test server, so i won't have to do any update anytime soon, the configuration on the real server will be done in a correct way, as you suggest. Thx a lot

-- GuillaumeBardy - 28 Aug 2007