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

At work (where I don't have root/sysadmin privilege nor much clout apparently with those that do), I'm trying to 'use' a module (DB_File) that was installed on my behalf in /local/perl5.8/lib in a cgi script that is served by:

SERVER_SOFTWARE="Oracle HTTP Server Powered by Apache/1.3.19 (Unix) mod_fastcgi/2.2.10 mod_perl/1.25 mod_oprocmgr/1.0"

Though I start the script with:

#!/local/perl5.8/bin/perl -w -I/local/perl5.8/lib/5.8.0

and DB_File is found, I get a '500 Internal Server Error' indicating that DB_File requires AutoLoader which in turn requires vars which, in the 5.00503 perl distribution, has a typo apparently:

Invalid [] range "a-Z" in transliteration operator at /oracle/iAS/1.0.2.2/Apache/perl/lib/5.00503/vars.pm line 17.
Compilation failed in require at /oracle/iAS/1.0.2.2/Apache/perl/lib/5.00503/AutoLoader.pm line 3.
BEGIN failed--compilation aborted at /oracle/iAS/1.0.2.2/Apache/perl/lib/5.00503/AutoLoader.pm line 3.
Compilation failed in require at /local/perl5.8/lib/5.8.0/sun4-solaris/DB_File.pm line 184.
BEGIN failed--compilation aborted at /local/perl5.8/lib/5.8.0/sun4-solaris/DB_File.pm line 184.
Compilation failed in require at /ncsa/cgi-bin/perlfect/search/test4.pl line 12.
BEGIN failed--compilation aborted at /ncsa/cgi-bin/perlfect/search/test4.pl line 12.
Thu Feb 20 16:49:11 2003 error client 127.0.0.1 Premature end of script headers: /ncsa/cgi-bin/perlfect/search/test4.pl

Here's the line from /oracle/iAS/1.0.2.2/Apache/perl/lib/5.00503/vars.pm:

if ($sym =~ tr/A-Za-Z_0-9//c) {

However, that the 5.00503 vars.pm has this invalid range, is sort of secondary to what I believe is the problem:

I can use or require by perl version choice only one level down; i.e., I get the perl5.8 DB_File (strangely the @INC of the version of perl that Apache starts with doesn't have it - in my search it seems to be standard or near core module or at least AnyDBM_File is) but get 5.00503 modules for any that are thus indirectly use-d or require-d.

I've tried various tacts to get a better vars.pm:

-require "/path to 5.8 libs/vars.pm";
- -I shell invocation parameter
-prepending 5.8 lib path to PERL5LIB ENV variable

to no avail. This is despite PERL5LIB and @INC set such that the 5.8 libs would be, and in the case of DB_File are, found. I don't know of another way that I can, as a user, modify how the web server looks for modules. I'm not sure if this is a mod_perl issue. I can look at the error logs and httpd.conf (there are Apache::Require lines there) but thus far haven't been able to get any server support types to help (maybe they don't know) beyond installing DB_File (and by dependence BerkeleyDB). I've suggested that someone just fix the typo but while I wait I've enlisted the help of your knowledge.

Your help is appreciated. Thanks.

Replies are listed 'Best First'.
Re: module problem between perl and Apache
by chromatic (Archbishop) on Feb 21, 2003 at 03:54 UTC

    Sounds like your mod_perl was built with Perl 5.5.3. If I were you, I'd not muck with @INC in this case. Instead, I'd do something like this: 

    BEGIN
{
    require '/path/to/DB_File.pm';
}

    [download]

    No guarantees -- your system sounds somewhat screwy, but I'd use that as my next try.

    Update: corrected minor text typo

[reply]
[d/l]
[select]
Re: module problem between perl and Apache
by iguanodon (Priest) on Feb 21, 2003 at 16:21 UTC
    Sorry, but I don't think this setup has any chance of working. You can't mix 5.8.0 modules with previous versions of Perl. And as chromatic points out, your mod_perl wasn't built with 5.8.0.

[reply]
Re: module problem between perl and Apache
by lintgrabber (Initiate) on Feb 21, 2003 at 15:48 UTC
    Thanks for the reply. I tried the BEGIN pre-compile require and still run into a problem at AutoLoader and vars modules. I seems that Apache, with mod_perl, uses the 5.00503 AutoLoader and vars modules in any case. I also tried to override (with 'use subs...') the function in vars that has the invalid range.

    A question I still have is if, possibly via httpd.conf, files in a directory can be served without mod_perl.

[reply]
Re: module problem between perl and Apache
by lintgrabber (Initiate) on Feb 22, 2003 at 00:19 UTC
    Thanks again. Though my cgi script still isn't working, I do have a better understanding of the situation.

    I wondered about modules and their perl version-ness or dependence relative to the version of perl used. I gather that this is determined by the version of perl used to install the module. I've seen modules that explicitly require a particular version of perl but not all do. The error log indicates a syntax like problem in a core module not a version mismatch.

    This raises a couple of questions:

    At what point and how is the perl version of a module compared to the perl version that is interpreting it? In this case after parsing, assuming parsing is where the invalid range is found.

    It's intuitive that a 5.8 module wouldn't work with perl 5.5.3 but what about the other way around? Would a 5.5.3 module work with 5.8?

    If so, is this motivation to run the latest version of perl available while installing modules with the earliest? Or are perl versions (and their libs) kept entirely separate?

    Please excuse my lack of experience.

[reply]

Back to Seekers of Perl Wisdom