Skip Menu |

This queue is for tickets about the PAR CPAN distribution.

Report information
The Basics
Id: 127971
Status: resolved
Priority: 0/
Queue: PAR

People
Owner: Nobody in particular
Requestors: welleozean [...] googlemail.com
Cc:
AdminCc:

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



Subject: {Windows] PAR-Packer-1.047
Date: Sat, 8 Dec 2018 16:14:44 +0100
To: bug-PAR [...] rt.cpan.org
From: Welle <welleozean [...] googlemail.com>

Hello,

with Strawberry Perl 5.28 32bit on Windows 10. I pack it with pp and at run-time - on a different machine - I get the following:

pp --% -u -x -l C:/berrybrew/5.28.0_32/perl/vendor/lib/MIME/types.db -o AC.exe -F Bleach="^(AC)" AC.pl

PS D:\6.00> .\AC.exe
format error: bad signature: 0x2508438b at offset 6962287 in file D:\6.00\AC.exe
 at -e line 614.
format error: bad signature: 0x8b0974c0 at offset 6962321 in file D:\6.00\AC.exe
 at -e line 614.
format error: bad signature: 0x24848b4c at offset 6962382 in file D:\6.00\AC.exe
 at -e line 614.
This is Win32
Can't load 'C:\Users\BD\AppData\Local\Temp\par-4244\cache-1544280014\31e69eb2.xs.dll' for module Tk::JPEG: load_file:Das angegebene Modul wurde nicht gefunden at C:/berrybrew/5.28.0_32/perl/lib/DynaLoader.pm line 193.
  at C:/berrybrew/5.28.0_32/perl/vendor/lib/PAR/Heavy.pm line 123.
Compilation failed in require at if.pm line 15.

I am quite worried about 2 things: the "format error: bad signature" which I do not know what it refers to and about the inability to read at C:/berrybrew/5.28.0_32/perl/lib/DynaLoader.pm which was the directory in the original machine where pp has been used!

On 2018-12-08 10:14:59, welleozean@googlemail.com wrote: Show quoted text
> pp --% -u -x -l C:/berrybrew/5.28.0_32/perl/vendor/lib/MIME/types.db > -o AC.exe -F Bleach="^(AC)" AC.pl
Is "--%" a typo - there's no such option for pp? Show quoted text
> PS D:\6.00> .\AC.exe > format error: bad signature: 0x2508438b at offset 6962287 in file > D:\6.00\AC.exe > at -e line 614.
... Show quoted text
> Can't load > 'C:\Users\BD\AppData\Local\Temp\par-4244\cache- > 1544280014\31e69eb2.xs.dll' for > module Tk::JPEG: load_file:Das angegebene Modul wurde nicht gefunden > at > C:/berrybrew/5.28.0_32/perl/lib/DynaLoader.pm line 193. > > I am quite worried about 2 things: the "format error: bad signature"
These are from Archive::Zip. Which version of Archive::Zip are you using (on the machine where you packed AC.exe)? Does your program use Archive::Zip explicitly? "Can't load..." is most likely caused by your program using Tk::JPEG, but you didn't pack the native JPEG library - PAR:Packer (actually Module::ScanDeps) does NOT detect dependencies of (XS) Perl modules on native libraries. If Tk::JPEG was built against the JPEG library that came with your Strawberry this can be solved by adding --link libjpeg-9_.dll to your pp command line. Show quoted text
> C:/berrybrew/5.28.0_32/perl/lib/DynaLoader.pm which was the directory > in the original machine where pp has been used!
Nothing to worry about, it's a feature. All Perl code that is packed by pp is instrumented with #line directives that encode the original file name (and line numbers in case POD stripping was applied) so that error messages correctly reference stuff as seen by the developer on the packing machine. Cheers, Roderich
Subject: Re: [rt.cpan.org #127971] {Windows] PAR-Packer-1.047
Date: Wed, 12 Dec 2018 12:15:47 +0100
To: bug-PAR [...] rt.cpan.org
From: welle Ozean <welleozean [...] googlemail.com>
"--%" is not a typo. Is the way to pass the command in Windows PowerShell. Archive::Zip: was 1.60 at the moment of packaging. Upgraded now to 1.64 (but using --force) Adding --link libjpeg-9_.dll doesn't solve the problem. Same error. Tried also with full path. (I guess it is okay that PAR searches for 31e69eb2.xs.dll (changing its name). Tk::JPEG has been compiled with cpanm Tk. Please, note that the same script (without adding --link) works out-of-the-box on my macOS. Any help to solve my problem would be very much appreciated. Thanks. On a side note: if I run the exe from the packaging machine, the script works. I guess it finds missing parts in original position. This makes debugging not very easy, as it requires to switch to another machine for testing (what is the best alternative to test the exe in the same machine?). Am So., 9. Dez. 2018 um 15:16 Uhr schrieb Roderich Schupp via RT < bug-PAR@rt.cpan.org>: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=127971 > > > On 2018-12-08 10:14:59, welleozean@googlemail.com wrote:
> > pp --% -u -x -l C:/berrybrew/5.28.0_32/perl/vendor/lib/MIME/types.db > > -o AC.exe -F Bleach="^(AC)" AC.pl
> > Is "--%" a typo - there's no such option for pp? >
> > PS D:\6.00> .\AC.exe > > format error: bad signature: 0x2508438b at offset 6962287 in file > > D:\6.00\AC.exe > > at -e line 614.
> ...
> > Can't load > > 'C:\Users\BD\AppData\Local\Temp\par-4244\cache- > > 1544280014\31e69eb2.xs.dll' for > > module Tk::JPEG: load_file:Das angegebene Modul wurde nicht gefunden > > at > > C:/berrybrew/5.28.0_32/perl/lib/DynaLoader.pm line 193. > > > > I am quite worried about 2 things: the "format error: bad signature"
> > These are from Archive::Zip. Which version of Archive::Zip are you using > (on the machine where you packed AC.exe)? Does your program use > Archive::Zip > explicitly? > > "Can't load..." is most likely caused by your program using Tk::JPEG, > but you didn't pack the native JPEG library - PAR:Packer (actually > Module::ScanDeps) does NOT detect dependencies of (XS) Perl modules > on native libraries. If Tk::JPEG was built against the JPEG library > that came with your Strawberry this can be solved by adding > > --link libjpeg-9_.dll > > to your pp command line. >
> > C:/berrybrew/5.28.0_32/perl/lib/DynaLoader.pm which was the directory > > in the original machine where pp has been used!
> > Nothing to worry about, it's a feature. All Perl code that is packed by pp > is instrumented with #line directives that encode the original file name > (and line numbers in case POD stripping was applied) so that error > messages correctly reference stuff as seen by the developer on the > packing machine. > > Cheers, Roderich > > > >
Subject: Re: [rt.cpan.org #127971] {Windows] PAR-Packer-1.047
Date: Wed, 12 Dec 2018 13:02:58 +0100
To: bug-PAR [...] rt.cpan.org
From: welle Ozean <welleozean [...] googlemail.com>
Adding also --link zlib1_.dll it works. However, the same problem occurs with all other missing .dll Unfortunately, the error message doesn't say the name of the dll missing (it has an arbitrary code), just the module referring to it, which makes it difficult to find the respective dlls Am So., 9. Dez. 2018 um 15:16 Uhr schrieb Roderich Schupp via RT < bug-PAR@rt.cpan.org>: Show quoted text
> Sun Dec 09 09:16:33 2018: Request 127971 was acted upon. > Transaction: Correspondence added by RSCHUPP > Queue: PAR > Subject: {Windows] PAR-Packer-1.047 > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: welleozean@googlemail.com > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=127971 > > > > On 2018-12-08 10:14:59, welleozean@googlemail.com wrote:
> > pp --% -u -x -l C:/berrybrew/5.28.0_32/perl/vendor/lib/MIME/types.db > > -o AC.exe -F Bleach="^(AC)" AC.pl
> > Is "--%" a typo - there's no such option for pp? >
> > PS D:\6.00> .\AC.exe > > format error: bad signature: 0x2508438b at offset 6962287 in file > > D:\6.00\AC.exe > > at -e line 614.
> ...
> > Can't load > > 'C:\Users\BD\AppData\Local\Temp\par-4244\cache- > > 1544280014\31e69eb2.xs.dll' for > > module Tk::JPEG: load_file:Das angegebene Modul wurde nicht gefunden > > at > > C:/berrybrew/5.28.0_32/perl/lib/DynaLoader.pm line 193. > > > > I am quite worried about 2 things: the "format error: bad signature"
> > These are from Archive::Zip. Which version of Archive::Zip are you using > (on the machine where you packed AC.exe)? Does your program use > Archive::Zip > explicitly? > > "Can't load..." is most likely caused by your program using Tk::JPEG, > but you didn't pack the native JPEG library - PAR:Packer (actually > Module::ScanDeps) does NOT detect dependencies of (XS) Perl modules > on native libraries. If Tk::JPEG was built against the JPEG library > that came with your Strawberry this can be solved by adding > > --link libjpeg-9_.dll > > to your pp command line. >
> > C:/berrybrew/5.28.0_32/perl/lib/DynaLoader.pm which was the directory > > in the original machine where pp has been used!
> > Nothing to worry about, it's a feature. All Perl code that is packed by pp > is instrumented with #line directives that encode the original file name > (and line numbers in case POD stripping was applied) so that error > messages correctly reference stuff as seen by the developer on the > packing machine. > > Cheers, Roderich >
On 2018-12-12 06:16:12, welleozean@googlemail.com wrote: Show quoted text
> Adding --link libjpeg-9_.dll doesn't solve the problem. Same error. Tried > also with full path. (I guess it is okay that PAR searches for > 31e69eb2.xs.dll (changing its name). Tk::JPEG has been compiled with cpanm > Tk.
I assume that 31e69eb2.xs.dll is the PAR mangled name for .../auto/Tk/JPEG/JPEG.xs.dll (please verify, e.g. by comparing MD5 or SHA1 digests). I suspect that this DLL hasn't been linked against the libjpeg*.dll that came with Strawberry. Or it is linked against additional DLLs that were not packed either. Try something like objdump -ax .../JPEG.xs.dll | grep "DLL Name" to determine its dependent DLLs. Show quoted text
> Please, note that the same script (without adding --link) works > out-of-the-box on my macOS.
Most likely because the shared libjpeg there is provided by the platform, hence available on both machines. Cheers, Roderich
On 2018-12-12 07:03:49, welleozean@googlemail.com wrote: Show quoted text
> However, the same problem occurs with all other missing .dll > Unfortunately, the error message doesn't say the name of the dll missing > (it has an arbitrary code), just the module referring to it, which makes it > difficult to find the respective dlls
Blame that on the OS: the string "Das angegebene Modul wurde nicht gefunden" is what Windows returns as explanation. But Windows (7 at least) also pops up a message that names the missing DLL. Cheers, Roderich
Subject: Re: [rt.cpan.org #127971] {Windows] PAR-Packer-1.047
Date: Wed, 12 Dec 2018 15:03:51 +0100
To: bug-PAR [...] rt.cpan.org
From: welle Ozean <welleozean [...] googlemail.com>
Your suggestion of using objdump -ax was very precious. With a bit of trying and testing I have been able to identify all needed dlls and include them in the executable. All works fine. You made my day. Best, Welle Am Mi., 12. Dez. 2018 um 14:59 Uhr schrieb Roderich Schupp via RT < bug-PAR@rt.cpan.org>: Show quoted text
> Wed Dec 12 08:59:38 2018: Request 127971 was acted upon. > Transaction: Correspondence added by RSCHUPP > Queue: PAR > Subject: {Windows] PAR-Packer-1.047 > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: welleozean@googlemail.com > Status: open > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=127971 > > > > On 2018-12-12 07:03:49, welleozean@googlemail.com wrote: >
> > However, the same problem occurs with all other missing .dll > > Unfortunately, the error message doesn't say the name of the dll missing > > (it has an arbitrary code), just the module referring to it, which makes
> it
> > difficult to find the respective dlls
> > Blame that on the OS: the string "Das angegebene Modul wurde nicht > gefunden" > is what Windows returns as explanation. But Windows (7 at least) also pops > up > a message that names the missing DLL. > > Cheers, Roderich >
Am Mi 12. Dez 2018, 07:03:49, welleozean@googlemail.com schrieb: Show quoted text
> Adding also --link zlib1_.dll it works. > > However, the same problem occurs with all other missing .dll > Unfortunately, the error message doesn't say the name of the dll missing > (it has an arbitrary code), just the module referring to it, which makes it > difficult to find the respective dlls
My reply on the list did not show up, so I retry via rt.cpan.org: you can use https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer to see which dlls are opened by your packed executable on the packing machine. The DLLs referenced there should either be in your PAR-cache-directory or windows system libraries. Christoph
And just to add a few extra data points, I have a script that uses objdump to find dependent DLLs on windows. It would need some edits to work on Linux, and a different approach to work on Macs, but it does the job for my use case. https://github.com/shawnlaffan/perl-pp-autolink The logic has been adapted from the pp_simple.pl script at https://www.perlmonks.org/?node_id=1148802 That script itself might work well enough for most use cases, I just did not need to check for all the extra WX stuff. There is also some similar logic in the build system that could perhaps be adapted to the more general packing case. https://github.com/rschupp/PAR-Packer/tree/master/myldr/find_files_to_embed Shawn. On Wed Dec 12 10:31:43 2018, LAMPRECHT wrote: Show quoted text
> Am Mi 12. Dez 2018, 07:03:49, welleozean@googlemail.com schrieb:
> > Adding also --link zlib1_.dll it works. > > > > However, the same problem occurs with all other missing .dll > > Unfortunately, the error message doesn't say the name of the dll > > missing > > (it has an arbitrary code), just the module referring to it, which > > makes it > > difficult to find the respective dlls
> > My reply on the list did not show up, so I retry via rt.cpan.org: > > you can use > https://docs.microsoft.com/en-us/sysinternals/downloads/process- > explorer > to see which dlls are opened by your packed executable on the packing > machine. > The DLLs referenced there should either be in your PAR-cache- > directory or windows system libraries. > > Christoph
Thank you Shawn and Christoph for your excellent suggestions. Cheers, Roderich