As most of you probably know, various modules (some of them using XS) are built into parl(.exe), the PAR binary loader which is prepended to any binary executables produced by pp, at build time.
I've just conducted a litle experiment and now I'm not so sure that this description of the workings of pp is correct... Anyway I used "strings -a parl" to determine what module versions had been packed into parl. For Compress::Zlib I found 1.41 for both the Perl module (Compress/Zlib.pm) and the XS part (Compress/Zlib.so). That's what was installed at the time I build PAR. Then I packed a one-liner: pp -o foo.exe -e 'print $Compress::Zlib::VERSION;' Running foo.exe prints "1.41" and inspection of foo.exe (again with strings -a) shows both parts of Compress::Zlib at 1.41. Next I upgraded Compress::Zlib to 1.42, but didn't rebuild PAR, pp'ed the one liner again and ran it: Compress::Zlib object version 1.41 does not match bootstrap parameter 1.42 at /homes/schuppr/lib/sun4-solaris/Compress/Zlib.pm line 100. Compilation failed in require at /homes/schuppr/lib/Archive/Zip.pm line 24. BEGIN failed--compilation aborted at /homes/schuppr/lib/Archive/Zip.pm line 24. Compilation failed in require at -e line 318. Inspection shows that the contained Compress/Zlib.pm is now at 1.42, but Compress/Zlib.so is still at 1.41, hence the "bootstrap version mismatch". This shows that some stuff in a pp'ed exe gets taken from the Perl environment at pp time while other stuff is taken from parl. Note: I used the PAR version at hand: 0.941. Another observation point: when you install PAR on Debian (package libpar-perl), parl doesn't have any modules packed in (that's because the executable gets stripped during Debian packaging which discards everything simply appended to the executable). But you can pp scripts just fine, the necessary modules are taken from the environment at pp time. (Of course, this Debian parl is no longer a self-contained perl loader, it only works when all necessary modules are present on the system.) Cheers, Roderich
