[rt.cpan.org #117323] parl a.par not finding DLL that was added with -l

[Bob Hallissy via RT]

Tue Aug 30 02:23:41 2016: Request 117323 was acted upon.
Transaction: Ticket created by BHALLISSY
Queue: PAR-Packer
Subject: parl a.par not finding DLL that was added with -l
Broken in: 1.035
Severity: (no value)
Owner: Nobody
Requestors: ***@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=117323 >


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)

[Roderich Schupp via RT]

Tue Aug 30 16:56:15 2016: Request 117323 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: parl a.par not finding DLL that was added with -l
Broken in: 1.035
Severity: (no value)
Owner: Nobody
Requestors: ***@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=117323 >

Post by Bob Hallissy via RT
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

[Bob Hallissy via RT]

Tue Aug 30 20:37:21 2016: Request 117323 was acted upon.
Transaction: Correspondence added by BHALLISSY
Queue: PAR-Packer
Subject: parl a.par not finding DLL that was added with -l
Broken in: 1.035
Severity: (no value)
Owner: Nobody
Requestors: ***@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=117323 >

Post by Roderich Schupp via RT
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

[Roderich Schupp via RT]

Wed Aug 31 03:05:22 2016: Request 117323 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: parl a.par not finding DLL that was added with -l
Broken in: 1.035
Severity: (no value)
Owner: Nobody
Requestors: ***@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=117323 >

Post by Bob Hallissy via RT
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?

Post by Bob Hallissy via RT
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

[Bob Hallissy via RT]

Mon Sep 05 18:30:37 2016: Request 117323 was acted upon.
Transaction: Correspondence added by BHALLISSY
Queue: PAR-Packer
Subject: parl a.par not finding DLL that was added with -l
Broken in: 1.035
Severity: (no value)
Owner: Nobody
Requestors: ***@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=117323 >

... 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

[Roderich Schupp via RT]

Tue Sep 06 11:13:01 2016: Request 117323 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: parl a.par not finding DLL that was added with -l
Broken in: 1.035
Severity: (no value)
Owner: Nobody
Requestors: ***@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=117323 >
$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

[Roderich Schupp via RT]

Fri Dec 30 06:37:13 2016: Request 117323 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: parl a.par not finding DLL that was added with -l
Broken in: 1.035
Severity: (no value)
Owner: Nobody
Requestors: ***@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=117323 >


Closing this ticket, no further action necessary.

Cheers, Roderich