Wed Jul 13 05:19:33 2011: Request 69443 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: parl.exe try to load dll from c:\strawberry\lib first
Broken in: (no value)
Severity: (no value)
Owner: RSCHUPP
Requestors: [email protected]
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=69443 >
On 2011-07-13 03:40:43, [email protected] wrote:
> After the module was installed. I can run the parl.exe correctly.
> Then I copy the parl.exe to c:\ and install strawberry-perl-5.10.4x86
under
> c:\strawberry. When I try to run the file c:\parl.exe, I got error
Looks like parl.exe (which in theory should be totally self-contained)
still looks for modules in C:\strawberry\... (i.e. the configuration
from where it was built) in preference to the modules packed
into parl.exe.
If it finds a module and its DLL in C:\strawberry\... it tries to load
that - and that won't work because Perl 5.12 and 5.10 have incompatible
ABIs. If there's nothing in C:\strawberry\... it falls back to
the built-in modules.
This behaviour might be caused by the fact that Strawberry Perl 5.12
contains a new version of XSLoader that breaks PAR::Packer's hack
to intercept loading of DLLs.
The fix for that is already in PAR::Packer's Subversion repository:
http://svn.openfoundry.org/par/PAR-Packer/trunk
Could you try that, i.e.
- re-install Straberry 5.12.3
- check out the above
- apply the patch from RT 57273 as before
- build it and save parl.exe
While you're at it: regarding that patch from RT 57273:
- does "dmake test" pass all tests?
- after "dmake install", please try to pack a minimal script
pp -o hello.exe -e "print qq[hello world\n]"
I'm interested in the output of
objdump -h hello.exe
in particular if it lists a resource section (".rsrc")
(objdump.exe is in C:\strawberry\c\bin).
Cheers, Roderich
