Bug 69671 – inconsistent/incorrect perl/mod_perl @INC path

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Nicholas Vinen 2004-10-31 15:23:21 UTC]

The default perl interpreter include path (@INC) on my system is:

$VAR1 = '/etc/perl';
$VAR2 = '/usr/lib/perl5/site_perl/5.8.4/i686-linux';
$VAR3 = '/usr/lib/perl5/site_perl/5.8.4';
$VAR4 = '/usr/lib/perl5/site_perl/5.8.2/i686-linux';
$VAR5 = '/usr/lib/perl5/site_perl/5.8.2';
$VAR6 = '/usr/lib/perl5/site_perl';
$VAR7 = '/usr/lib/perl5/vendor_perl/5.8.4/i686-linux';
$VAR8 = '/usr/lib/perl5/vendor_perl/5.8.4';
$VAR9 = '/usr/lib/perl5/vendor_perl/5.8.2/i686-linux';
$VAR10 = '/usr/lib/perl5/vendor_perl/5.8.2';
$VAR11 = '/usr/lib/perl5/vendor_perl';
$VAR12 = '/usr/lib/perl5/5.8.4/i686-linux';
$VAR13 = '/usr/lib/perl5/5.8.4';
$VAR14 = '/usr/local/lib/site_perl';
$VAR15 = '/usr/lib/perl5/site_perl/5.8.2/i686-linux';
$VAR16 = '/usr/lib/perl5/site_perl/5.8.2';
$VAR17 = '.';

This seems correct to me. site_perl and vendor_perl come first so that upgraded packages installed after perl take precendence over those which the perl package itself installs.

This is the @INC I get from files launched from Apache-1.3.33 via mod_perl:

$VAR1 = '/usr/lib/perl5/5.8.4/i686-linux';
$VAR2 = '/usr/lib/perl5/5.8.4';
$VAR3 = '/usr/lib/perl5/site_perl/5.8.4/i686-linux';
$VAR4 = '/usr/lib/perl5/site_perl/5.8.4';
$VAR5 = '/usr/lib/perl5/site_perl/5.8.2/i686-linux';
$VAR6 = '/usr/lib/perl5/site_perl/5.8.2';
$VAR7 = '/usr/lib/perl5/site_perl';
$VAR8 = '/usr/lib/perl5/vendor_perl/5.8.4/i686-linux';
$VAR9 = '/usr/lib/perl5/vendor_perl/5.8.4';
$VAR10 = '/usr/lib/perl5/vendor_perl/5.8.2/i686-linux';
$VAR11 = '/usr/lib/perl5/vendor_perl/5.8.2';
$VAR12 = '/usr/lib/perl5/vendor_perl';
$VAR13 = '.';
$VAR14 = '/etc/apache/';
$VAR15 = '/etc/apache/lib/perl';

The problem is, older versions of packages installed along with the perl interpreter are included before the newer ones installed in the site_perl/vendor_perl directories, causing errors when I "use" certain packages. I can "use" them fine from the command-line perl interpreter, but not in files interpreted via apache.

I think this might be a configuration problem with the mod_perl ebuild but I'm not sure. As far as I know I haven't done anything to change these paths. I can provide more information if necessary, please contact me. For now I will work-around by setting @INC myself.

Thanks,
Nicholas

[Comment 1 Robert Coie (RETIRED) 2004-11-08 14:48:46 UTC]

I have also noticed this, and haven't tracked the cause down yet.  One thing I
have discovered is that if i cleaned out all site_perl directories completely,
and reemerged libperl and perl, mod_perl got the right @INC.

[Comment 2 Eric Brown 2005-02-01 12:00:24 UTC]

should we bump this up to MAJOR? I think the broken INC path is breaking applications like RT that require things like MIME::QuotedPrint.pm > 3.03

[Comment 3 Nicholas Vinen 2005-02-01 12:03:16 UTC]

Yes, I originally had this problem with RT. If I weren't a perl programmer of sorts I'd have had serious problems. I'll leave it up to you though.

I regularly re-emerge perl, mod_perl and all my perl modules, it doesn't seem to help. You may be right that if you nuke the site_perl directories it will fix it but there are some modules I downloaded via CPAN because there are no ebuilds, and I don't really want to delete them.

[Comment 4 Eric Brown 2005-02-01 12:26:40 UTC]

I just tried removing site_perl and re-emerging that stuff, it does not work.

Is there _any_ temporary workaround for this?  I lost RT and I need it back ASAP, hack or no hack.  Is reinstalling gentoo the only way?

[Comment 5 Nicholas Vinen 2005-02-01 12:30:00 UTC]

I have a highly customised installation but here is what I do (it's a bit hacky).

Edit RT's "webmux.pl" in the bin directory.
Inside the topmost BEGIN { block, add something like the following:

    @INC = ('/usr/lib/perl5/site_perl/5.8.5/i686-linux',
            '/usr/lib/perl5/site_perl/5.8.5',
            '/usr/lib/perl5/site_perl/5.8.2/i686-linux',
            '/usr/lib/perl5/site_perl/5.8.2',
            '/usr/lib/perl5/site_perl',
            '/usr/lib/perl5/vendor_perl/5.8.5/i686-linux',
            '/usr/lib/perl5/vendor_perl/5.8.5',
            '/usr/lib/perl5/vendor_perl/5.8.2/i686-linux',
            '/usr/lib/perl5/vendor_perl/5.8.2',
            '/usr/lib/perl5/vendor_perl',
            '/usr/lib/perl5/5.8.5/i686-linux',
            '/usr/lib/perl5/5.8.5',
            '/usr/local/lib/site_perl',
            '/usr/lib/perl5/site_perl/5.8.2/i686-linux',
            '/usr/lib/perl5/site_perl/5.8.2',
            '.',
            '/etc/apache/',
            '/etc/apache/lib/perl');

of course 5.8.5, 5.8.2 etc. depend upon your perl version. The easiest way to generate the correct list is to run a small perl script on the shell. something like:

perl -e 'print join("\n",@INC)'

And then stick the apache paths on the end. This overrides the built in path and allows it to work. Hope that helps as a work-around for now.

[Comment 6 Eric Brown 2005-02-01 16:24:43 UTC]

cool thanks :)

[Comment 7 Michael Cummings (RETIRED) 2005-02-06 05:29:57 UTC]

*** Bug 80466 has been marked as a duplicate of this bug. ***

[Comment 8 Michael Cummings (RETIRED) 2005-08-13 17:08:18 UTC]

this was fixed when the reverse inc patch was applied to the generation of
libperl as well.