Prototype mismatch under ModPerl::PerlRun

[Brian Wakem]

I am getting some errors (or is it a warning?) using mod_perl
(ModPerl:erlRun)

Prototype mismatch: sub
ModPerl::ROOT::ModPerl:erlRun::usr_local_apache2_MyScript::gettimeofday:
none vs () at /usr/lib/perl5/5.8.5/Exporter.pm line 65.


A number of scripts are producing this error, however each script completes
its task and outputs exactly what it is expected to output.


Can I ignore this or does it need my attention?

 

[Paul Lalli]

I am getting some errors (or is it a warning?) using mod_perl
(ModPerl:erlRun)

You can answer this question yourself by checking the relevant
documentation:

perldoc perldiag
Prototype mismatch: %s vs %s
(S unsafe) The subroutine being declared or defined had
previously been declared or defined with a different
function prototype.

The "S" there, as shown at the beginning of the relevant perldoc,
stands for "Severe Warning"

Prototype mismatch: sub
ModPerl::ROOT::ModPerl:erlRun::usr_local_apache2_MyScript::gettimeofday:
none vs () at /usr/lib/perl5/5.8.5/Exporter.pm line 65.

Reading the description of the error message, it would seem that the
subroutine gettimeofday was at one point declared or defined with an
empty prototype, like so:
sub gettimeofday();
OR
sub gettimeofday() {
#code here...
}

but at another point declared/defined without a prototype, like so
sub gettimeofday;
OR
sub gettimeofday {
#code here...
}

The fact that you're getting this message from within Exporter makes me
wonder if perhaps you're using two or more modules that both export
their own gettimeofday subroutine. That, however, is a random guess on
my part.

Figure out where the two instances of gettimeofday() are coming from.
If they refer to the same subroutine, fix the prototypes. If they are
different subroutines, fix the 'use' or 'import' calls to only import
one of the two modules' gettimeofday() subroutine.

Can I ignore this or does it need my attention?

I can't imagine ever "ignoring" a warning. One that Perl calls a
"severe" warning even more so. Find the bug, and fix it.

Paul Lalli

 

[Brian Wakem]

You can answer this question yourself by checking the relevant
documentation:

perldoc perldiag
Prototype mismatch: %s vs %s
(S unsafe) The subroutine being declared or defined had
previously been declared or defined with a different
function prototype.

The "S" there, as shown at the beginning of the relevant perldoc,
stands for "Severe Warning"

Oh dear.

Reading the description of the error message, it would seem that the
subroutine gettimeofday was at one point declared or defined with an
empty prototype, like so:
sub gettimeofday();
OR
sub gettimeofday() {
#code here...
}

but at another point declared/defined without a prototype, like so
sub gettimeofday;
OR
sub gettimeofday {
#code here...
}

The fact that you're getting this message from within Exporter makes me
wonder if perhaps you're using two or more modules that both export
their own gettimeofday subroutine. That, however, is a random guess on
my part.

It seems I can reproduce the error with just these few lines:-

#!/usr/bin/perl

use strict;
use CGI;
use Time::HiRes qw( gettimeofday );

my $query = new CGI;
print $query->header();
print "Test\n";

I do not get the error when it is run under mod_cgi, so I think it must be a
mod_perl specific warning.

Figure out where the two instances of gettimeofday() are coming from.
If they refer to the same subroutine, fix the prototypes. If they are
different subroutines, fix the 'use' or 'import' calls to only import
one of the two modules' gettimeofday() subroutine.


I can't imagine ever "ignoring" a warning. One that Perl calls a
"severe" warning even more so. Find the bug, and fix it.

Paul Lalli

Further googling has shown that a number of people have had this problem
before but there doesn't seem to be a solution. Perhaps its a bug in
mod_perl?

 

[Brian Wakem]

Further googling has shown that a number of people have had this problem
before but there doesn't seem to be a solution. Perhaps its a bug in
mod_perl?

Even further googling has only suggested that it *is* a bug in mod_perl
(PerlRun, not Registry) and can be safetly ignored.