Wed Feb 10 04:59:03 2010: Request 42986 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR
Subject: PAR-based modules use system XS modules over included modules
Broken in: 0.984
Severity: Important
Owner: Nobody
Requestors: t...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=42986 >
On Wed Feb 10 01:44:53 2010, TJC wrote:
> Should this issue still occur with executable packed archives?
> I ask because I am having a shot at that method instead, but still seem
> to be having the same problem.
Basically it's the same problem, but at least you can do
something about it :)
The packed executable has the same chicken-and-egg problem
as the .par archive. As a first approximation, a packed
executable is just a custom built perl interpreter with
a .par bolted on. In order to get at the stuff in the .par
you need a minimal set of Perl modules. A .par takes these
from the Perl environment where it is run (and doesn't
care if different versions of these modules are included in
the .par). The packed executable takes these modules from its
own executable file (NOT from the appended .par). You may find
them extracted below /tmp/par-username/cache-xxxx/, but you
probably won't recognize them, because their file names have
been mangled (some-checksum.pm). If you find, say, a File::Temp
in the cache area that actually is called File/Temp.pm then this
is the one extracted from the .par, but as in the .par case,
it's not the one that gets loaded.
See one of my earlier comments how to find out about
the "built-in" modules in a packed executable.
Which version of a specific module is "built-in" depends
on the environment that was current when PAR::Packer was built.
(That's why I asked where you got your PAR::Packer from.)
If you rebuild PAR::Packer on your building system
it will pick up the current versions of these modules.
