Tue Aug 24 17:21:48 2010: Request 59710 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Par-Packer not including all dependencies
Broken in: (no value)
Severity: (no value)
Owner: RSCHUPP
Requestors: [email protected]
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=59710 >
On 2010-08-24 06:55:10, [email protected] wrote:
> Here is the result:
>
> $ pp -o ucd.exe -e "use Unicode::UCD qw(charinfo); my $i =
> charinfo(0x42); print $i->{name};"
> $./ucd.exe
> cleaning INC except
> ^\/var\/tmp\/\/par\-root\/cache\-6ff017174559c9b84c2aa41e0b8cf6a3d998a53c
Thanks for following up.
Just as I suspected: note the double (escaped) slash
in /var//tmp/par-root/...
This will causes too much (anything but the code refs) to
be cleaned from @INC, causing your original problem.
I wonder where this double slash came from - just out of
curiosity, can you look up how P_tmpdir is #define'd
in /usr/include/stdio.h on your machine?
Anyway, the fix is in sight!
Please change line ~1690 in lib/PAR/Packer.pm from
my $par_temp_dir = quotemeta( $ENV{PAR_TEMP} );
to
my $par_temp_dir = quotemeta( File::Spec->catdir($ENV{PAR_TEMP}) );
(you may leave in the print statements from the previous
patch). That should do the trick.
If you really want to know what's happening:
- the special Perl interpreter in any packed executable still
starts with the standard Perl module search @INC path
- during bootstrapping, when stuff gets extracted from the executable
somewhere beneath the cache directory, @INC gets augmented
with some directories beneath the cache directory and also
some code refs
- we don't want your original script to execute with anything
from the standard Perl module path (if you packed with -B) in @INC:
it might pick up modules from the machine where it is running
(instead of the packed stuff from the build machine), but these
could be different, even incompatible, leading to hard to diagnose
strange behaviour
- so immediately before your original script is executed, we strip
anything "illegitimate" from @INC
- "legitimate" are code refs and paths pointing beneath the
cache directory (given by $ENV{PAR_TEMP})
- the latter check is done literally, so the double slash
in $ENV{PAR_TEMP} makes the match fail (as the output shows,
the actual paths in @INC don't contain double slashs)
And why is there a double slash in $ENV{PAR_TEMP}, but none in
the actual paths since they are computed by appending
to $ENV{PAR_TEMP}? Probably because these paths are constructed
using File::Spec::catdir which canonicalizes its result.
But $ENV{PAR_TEMP} is originally constructed from C code
from the environment (e.g. $TMPDIR) or system defaults (e.g. P_tmpdir),
so any double slash or trailing slash found there is propagated
into $ENV{PAR_TEMP}.
Cheers, Roderich
