Skip Menu |
 

This queue is for tickets about the PAR-Packer CPAN distribution.

Report information
The Basics
Id: 117323
Status: resolved
Priority: 0/
Queue: PAR-Packer

People
Owner: Nobody in particular
Requestors: bhallissy [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 1.035
Fixed in: (no value)



Subject: parl a.par not finding DLL that was added with -l
Download (untitled) / with headers
text/plain 2.4k
Summary: Using 32-bit Strawberry perl 5.24.0 on Windows; PAR::Packer v1.035. Build a.par and a.exe as follows: pp -p -B -c -l some.dll myprog.pl pp -o a.exe a.par I now have two ways to run the program: a.exe or parl a.par but when I use the parl approach, the dll is loaded from C:\Strawberry rather from the unpacked PAR cache. Is this expected? Am I missing a parameter somewhere? Details: I'm trying to get XML::Parser::Expat to work in a .par file for distributing a package. Taking some hints from PerlMonks, I have installed ListDLLs.exe (https://technet.microsoft.com/en-us/sysinternals/bb896656.aspx) to help figure out where the DLL is being loaded. Turning this into a one-liner I get: pp -p -B -c -l libexpat-1_.dll -e "use XML::Parser::Expat; print XML::Parser::Expat->VERSION, `ListDLLs.exe $$`, join($/, @INC) " pp -o a.exe a.par When I execute a.exe, the ListDLLs output shows that the library was loaded from the cache: 0x62200000 0x19000 ...\par-494555736572\cache-60267defee8028cf3b2a13f4019904acfa2b57f9\01f5bf5f.xs.dll 0x6f940000 0x2c000 ...\par-494555736572\cache-60267defee8028cf3b2a13f4019904acfa2b57f9\libexpat-1_.dll However, when I try running the program via parl, the library that is in the cache isn't used: 0x62200000 0x19000 ...\par-494555736572\cache-05fd90c5e7a752b0fb90f30dbe8ed3fddef8e1e4\01f5bf5f.xs.dll 0x6f940000 0x2c000 C:\Strawberry\c\bin\libexpat-1_.dll Investigating further, it appears that the library is included twice in the cache from a.exe, but only one for that of a.par: cache-60267defee8028cf3b2a13f4019904acfa2b57f9\libexpat-1_.dll cache-60267defee8028cf3b2a13f4019904acfa2b57f9\inc\shlib\MSWin32-x86-multi-thread-64int\libexpat-1_.dll cache-05fd90c5e7a752b0fb90f30dbe8ed3fddef8e1e4\inc\shlib\MSWin32-x86-multi-thread-64int\libexpat-1_.dll The other output from my test shows that I'm using XML::Parser::Expat v2.44, and @INC is essentially the same in both cases: C:\Users\IEUser\AppData\Local\Temp\par-494555736572\cache-60267defee8028cf3b2a13f4019904acfa2b57f9\inc\lib C:\Users\IEUser\AppData\Local\Temp\par-494555736572\cache-60267defee8028cf3b2a13f4019904acfa2b57f9\inc CODE(0x1eff76c) CODE(0x1eff964) and C:\Users\IEUser\AppData\Local\Temp\par-494555736572\cache-05fd90c5e7a752b0fb90f30dbe8ed3fddef8e1e4\inc\lib C:\Users\IEUser\AppData\Local\Temp\par-494555736572\cache-05fd90c5e7a752b0fb90f30dbe8ed3fddef8e1e4\inc CODE(0x1edb23c) CODE(0x1edb434)
Download (untitled) / with headers
text/plain 556b
On 2016-08-30 02:23:41, BHALLISSY wrote: Show quoted text
> but when I use the parl approach, the dll is loaded from C:\Strawberry > rather from the unpacked PAR cache. > > Is this expected? Am I missing a parameter somewhere?
While it's reasonable to assume, it won't actually work. The DLL problem ist just one aspect that works in a packed executable, but not in .par + parl. Another is data files, either packed explicitly with "-a" or implicitly for modules who are known to install stuff besides the actual Perl code. Stick to packed excutables. Cheers, Roderich
Download (untitled) / with headers
text/plain 854b
On Tue Aug 30 16:56:15 2016, RSCHUPP wrote: Show quoted text
> While it's reasonable to assume, it won't actually work. > The DLL problem is just one aspect that works in a packed executable, > but not in .par + parl. Another is data files, either packed > explicitly with "-a" or implicitly for modules who are known to > install stuff besides the actual Perl code.
I take it this is a change from earlier releases, as our previous release seems to work OK. Be that as it may... We have 31 separate scripts bundled in one par. If we create a packed executable that includes them all, is there a way (other than copying the .exe file) to invoke specific scripts -- preferably: are their commandline parameters I can use to launch individual scripts? I'd hate to have to install 31 copies of the .exe file. On Linux and Mac I could use ln, but on Windows...? Bob
Download (untitled) / with headers
text/plain 763b
Am 2016-08-30 20:37:21, BHALLISSY schrieb: Show quoted text
> We have 31 separate scripts bundled in one par.
So users invoke them as parl some.par foo.pl parl some.par bar.pl ... where foo.pl, bar.pl are packed in some.par? Show quoted text
> If we create a packed > executable that includes them all, is there a way (other than copying > the .exe file) to invoke specific scripts
Pack a main script such as my $which = shift @ARGV; # note: probably should do some sanitizing my $rc = do "$ENV{PAR_TEMP}/script/$which"; die $@ if !defined $rc && $@; # script not found, failed to compile etc exit(0); # in case script didn't call exit() itself into some.exe, then users can invoke this as some.exe foo.pl some.exe bar.pl ... Cheers, Roderich
Download (untitled) / with headers
text/plain 865b
On Wed Aug 31 03:05:22 2016, RSCHUPP wrote: Show quoted text
> ... then users can invoke this as > > some.exe foo.pl > some.exe bar.pl > ...
Thanks, Roderich. I've been able to get this to work save one remaining problem: pod2usage() called from, say foo.pl, doesn't find the POD from foo.pl, but rather from main.pl. I've tried setting $0, e.g. in the main.pl script: my $which = shift @ARGV; # sanitizing goes here ... $0 = "$ENV{PAR_TEMP}/inc/script/$which" my $rc = do $0; ... and while this works if I try: perl main.pl foo.pl it doesn't work once packed into the binary (at least on Windows). Any simple tricks up your sleeve for this one? I suspect I could modify all the target scripts and, for example detecting presence of $ENV{PAR_TEMP} I could manually set the -input option to pod2usage, but I was hoping for a simpler solution... Bob
Download (untitled) / with headers
text/plain 517b
Am 2016-09-05 18:30:37, BHALLISSY schrieb: Show quoted text
> I've tried setting $0, e.g. in the main.pl script:
$0 in a pp generated executable is set to the name of the executable - so that a simple die "usage: $0 ...\n" will come out right. But that's wrong for Pod::Usage, so pp patches the packed copy of Pod/Usage.pm to use "$ENV{PAR_0} || $0" in place of "$0". Hence you should use $ENV{PAR_0} = "$ENV{PAR_TEMP}/inc/script/$which"; to trick Pod::Usage into using the POD in the script being "do"ne. Cheers, Roderich
Closing this ticket, no further action necessary. Cheers, Roderich


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.