Re^5: Imager::File::TIFF Dependencies

Thanks for the code and pp version.

I can reproduce the issue using Strawberry perl 5.24.1 with pp 1.036 (tested using a second cmd window with no perl in the path).

The issue appears to be an interaction between PAR::Packer packing dlls using their CRC32 checksums, but XSLoader does not (cannot) know that the names have changed in the packed directories and so calls the original name. This results in the error reported at line 11 of Imager::File::TIFF.

The PAR::Packer change log indicates it was updated to handle XSLoader changes in version 1.010 - https://metacpan.org/changes/distribution/PAR-Packer. Possibly some more recent changes in XSLoader are not being handled by PAR::Packer? (https://metacpan.org/changes/distribution/XSLoader).

It is probably worth taking this to the PAR::Packer mailing list or report an issue via rt: https://rt.cpan.org/Public/Dist/Display.html?Name=PAR-Packer.

... and on looking at the RT queue, there is a recent ticket that looks very similar to this issue, so it might be a more general problem: https://rt.cpan.org/Public/Bug/Display.html?id=120127.

Maybe try an older version of PAR::Packer?

Shawn.

Update: Just tried with pp 1.030 under Strawberry perl 5.22.2 and get the same error.

Update 2: It looks like the XSLoader code is patched by PAR::Filter::PatchContent and ultimately passes through to &DynaLoader::bootstrap_inherit. I don't know the innards of Dynaloader, but it leads me to think the RT ticket listed above has the same root cause. Others will no doubt have more informed ideas.

Comment on Re^5: Imager::File::TIFF Dependencies

Replies are listed 'Best First'.
Re^6: Imager::File::TIFF Dependencies by Anonymous Monk on May 24, 2017 at 01:41 UTC
The issue appears to be an interaction between PAR::Packer packing dlls using their CRC32 checksums, but XSLoader does not (cannot) know that the names have changed in the packed directories and so calls the original name. This results in the error reported at line 11 of Imager::File::TIFF. No. If that was the issue PAR::Packer would not work for anything. If you want to find out what the issue is use depends.exe `depends.exe /c /f:1 /pb /ot:temp.txt packed.exe arg1 arg2`	[reply] [d/l]
Re^7: Imager::File::TIFF Dependencies by swl (Parson) on May 24, 2017 at 03:05 UTC
Bah! I should have known to use Dependency Walker, having put it to this exact use in the past. Running it on the pp generated exe file does not work, though, as it is a self extracting zip archive which then starts a perl process which depends.exe does not see. However, running it directly on the original xs.dll file works. `depends.exe C:\berrybrew\5.24.1_64_PDL\perl\vendor\lib\auto\Imager\File\TIFF\TIFF.xs.dll` This returns the usual windows components, as well as PERL524.DLL, and LIBTIFF-5.DLL. The latter is the important part, and in turn depends on LIBJPEG-9__.DLL, LIBLZMA-5__.DLL and ZLIB1__.DLL. The libtiff dll and its dependencies need to be packed with the executable, or in the user's path, for the packed exe to work. A working packer command should therefore be something like this (updating the paths as appropriate): `pp -x --link c:\berrybrew\5.24.1_64_PDL\c\bin\libtiff-5__.dll --link c:\berrybrew\5.24.1_64_pdl\c\bin\LIBJPEG-9__.DLL --link c:\berrybrew\5.24.1_64_pdl\c\bin\LIBLZMA-5__.DLL --link c:\berrybrew\5.24.1_64_pdl\c\bin\ZLIB1__.DLL -o outputname.exe scriptname.pl` It works for me on my system. Shawn	[reply] [d/l] [select]
Re^8: Imager::File::TIFF Dependencies by BrentD (Sexton) on May 24, 2017 at 19:48 UTC
Many thanks. I was not familiar with depends.exe. I will get to know it now.	[reply]


Syntactic Confectionery Delight
	PerlMonks