Roderich Schupp schrieb:
On 5 Nov 2006 17:10:57 -0000, Rafael Garcia-Suarez wrote
One possibility is that you're using an old version of Scalar::Util.
refaddr() has been added in 1.09.
Yeah, that's my guess, too. But the real problem is:
why does it show only for the PAR-packed case?
Possible explanations:
- Scalar::Util (from packing system) isn't packed in,
older version from executing system is used instead
TODO: why wasn't it detected by Module::ScanDeps?
- Scalar::Util is packed in, but still the older version is used
TODO: check @INC of packed executable
- somehow older Scalar::Util is packed in, because
PAR was built on another system, or built on the packing system,
but with an older version of perl or Scalar::Util and this
old version has been frozen into PAR and is injected
from there into newly packed executables (I just checked:
parl.exe - the prototypical packed executable - definitely
has a copy of Scalar::Util embedded)
TODO: anamnesis of PAR on the packing machine
My money is on option three.
I removed the static @INC entries in "main.pl" if -B is in effect in a
recent PAR release, so option one is unlikely. (It would not have found
the local Scalar::Util without a path in @INC.) That point makes option
two unlikely as well.
At its core, option three is basically the issue we thought about
circumventing by replacing parl.exe with an unzip in the
pl-to-binary-executable case.
The thought occurred to me that we might solve this problem by appending
the required modules to a stripped-down copy of parl.exe just before
packaging. That's probably not simpler than the unzip approach and is
certainly slower, but it doesn't introduce the trouble with cleaning-up,
etc. All code might just continue to work because we're not really
changing parl.exe.
I'll look into this if I find the time, but don't hold your breath.
Steffen
