Bug #117323 for PAR-Packer: parl a.par not finding DLL that was added with -l

Tue Aug 30 02:23:41 2016 bhallissy [...] cpan.org - Ticket created

Subject:

parl a.par not finding DLL that was added with -l

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)

Tue Aug 30 16:56:15 2016 RSCHUPP [...] cpan.org - Correspondence added

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

Tue Aug 30 16:56:16 2016 The RT System itself - Status changed from 'new' to 'open'

Tue Aug 30 20:37:21 2016 bhallissy [...] cpan.org - Correspondence added

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

Wed Aug 31 03:05:22 2016 RSCHUPP [...] cpan.org - Correspondence added

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

Mon Sep 05 18:30:37 2016 bhallissy [...] cpan.org - Correspondence added

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

Tue Sep 06 11:13:01 2016 RSCHUPP [...] cpan.org - Correspondence added

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

Fri Dec 30 06:37:13 2016 RSCHUPP [...] cpan.org - Correspondence added

Closing this ticket, no further action necessary. Cheers, Roderich

Fri Dec 30 06:37:24 2016 RSCHUPP [...] cpan.org - Status changed from 'open' to 'resolved'