> You are right on. The packed exe has version 1.07, and the script is
> written, and using 1.18. Now, if only I can get it to use 1.18....
>
> use Scalar::Util 1.18 qw/refaddr/ doesn't seem to work....
>
> Oddly, when I unzip the exe that I have created with pp, the 1.18
> version is actuall in the LIB/SCALAR/ directory, but it
> doesn't seem to
> get loaded at runtime, even with:
> use Scalar::Util 1.18
The latter only checks that Scalar::Util should have at least
version 1.18 or die otherwise - it doesn't mean try another
Scalar::Util down the road whether it may satisfy the version
constraint.
The real problem is the way pp generates executables
(read on at your own risk :)
The basic idea is: just create a PAR archive and make it into
an executable. But in order to get to the perl modules
in the PAR we already must have PAR.pm loaded. And PAR.pm
requires other modules, e.g. Archive::Zip which require
others, e.g. Scalar::Util. So the PAR distribution
creates a standalone, statically linked, special purpose
version of the perl executable: that's basically what
parl.exe is. Before the perl interpreter in this special-built
perl variant is start, some things are done from C functions,
e.g. setup the cache directory, copy the perl shared library
into do (from C arrays contained in parl.exe) and set $ENV{PART_TEMP}
to it. Then the perl interpreter gets started with a little bootstrap
Perl code that is hand-crafted not to use any modules at all.
It extracts the modules absolutely necessary to access a PAR
archive by pure-perl means form the pp'ed executable itself
(this data is not in the PAR archive part, it has been simply
appended to the executable with special markers and headers
taht you can see if you run "strings" on the executable). Once
this modules have been extracted to the cache area, the
bootstrap code "require"s them. Now the code is able to
load the rest of the modules from the PAR archive (that has also
been appended to the executable and which is accessible by
running "unzip" on the executable) as if you had said
"perl -MPAR -Ifoo.exe ...".
The consequence is that building a PAR distribution captures
the state of your perl distribution (the version of perl itself
and that of several core and non-core modules) at the time of
the build (essentially this is frozen into parl.exe). If you install
another
version of perl or upgrade core modules (without rebuilding PAR),
pp'ed executables afterwards might behave differently than the original
scripts, because the use the captured versions. Sometimes these
differences will already show on the build machine, at other times
they only manifest themselves in another environment.
Perhaps the PAR build process should remember checksums of all
the stuff that goes into parl.exe and recheck against the
actually installed versions at pp'ing time and at least warn you
to better rebuild your PAR.
Cheers, Roderich
