On Wed, Aug 13, 2008 at 5:52 PM, Wes Hardaker
<[EMAIL PROTECTED]> wrote:
> I'd say it's definitely a problem with a 5.10+ perl
Yup, it's caused by the following innocent change in DynaLoader.pm
(in sub bootstrap):
perl 5.8.8:
last if $file = ($do_expand) ? dl_expandspec($try) : ((-f $try) &&
$try);
perl 5.10.0 (if $^O ne "VMS"):
last if $file = (-f $try) && $try;
This renders moot a horrible kludge in PAR::Heavy. It tries to get
DynaLoader to load IO.so etc that have already been extracted into
PAR's cache directory, but with mangled names like fa320d1a.so.
By setting $DynaLoader::do_expand = 1 and replacing
DynaLoader::dl_expandspec with sub { return }, PAR::Heavy
was able to make the above line always fail. That would result
in getting DynaLoader::dl_findfile getting called, but PAR::Heavy
replaced this also with a hacked version which would return
fa320d1a.so when asked to find IO.so.
In Perl 5.10.0 this doesn't work and DynaLoader proceeds as originally
intended and finds the _installed_ IO.so. Note that the kludge
in PAR::Heavy will work if IO.so is _not_ found along the
built-in @INC. This suggests that the following patch should
fix your problem:
--- PAR-Packer-0.982-ORIG/script/par.pl 2008-08-15 00:57:12.000000000 +0200
+++ PAR-Packer-0.982/script/par.pl 2008-08-15 00:57:32.000000000 +0200
@@ -337,7 +337,7 @@
}
die "Bootstrapping failed: cannot find $module!\n";
- }, @INC);
+ });
# Now load all bundled files {{{
It clears @INC during the early extraction phase and only leave a special
sub in @INC that is able to load perl _modules_ with their mangled names.
And indeed, the "hello world" example works - strace shows that
neither installed Perl modules, nor their corresponding installed
shared libraries are loaded.
Unfortunately the above patch breaks "make test". Some tests fail
when calling par.pl with the "bundle core modules" option _off_.
In that case, clearing @INC is wrong and results in errors like
"Can't locate XSLoader.pm in @INC" .
Cheers, Roderich
