torsten.foertsch at gmx
Jun 27, 2008, 10:35 AM
Post #1 of 3
(685 views)
Permalink
|
|
possible bug in Apache2::XSLoader and APR::XSLoader
|
|
Hi,
what is the purpose of Apache2::XSLoader and APR::XSLoader?
Both modules contain a load() function that reads:
sub load {
return unless BOOTSTRAP;
XSLoader::load(@_);
}
I believe this is wrong. The XSLoader::load function contains this code:
my @modparts = split(/::/,$module);
my $modfname = $modparts[-1];
my $modpname = join('/',@modparts);
my $modlibname = (caller())[1];
my $c = @modparts;
$modlibname =~ s,[\\/][^\\/]+$,, while $c--; # Q&D basename
my $file = "$modlibname/auto/$modpname/$modfname.$dl_dlext";
You see $modlibname is built from the caller's filename. If APR::XSLoader is
used this caller is /path/to/APR/XSLoader.pm and not as expected by the code
the filename of the caller of APR::XSLoader::load.
As a result XSLoader tries to load the shared lib from the wrong location.
A simple change makes it work as expected:
goto &XSLoader::load;
This way instead of pushing a new frame on the call stack the current
(APR::XSLoader::load) frame is replaced by XSLoader::load. Hence caller()
sees the original caller.
Torsten
|
XSLoader.diff
