in reply to Re^2: Imager::File::TIFF Dependencies
in thread Imager::File::TIFF Dependencies

If you can post a minimal example program which replicates your problem, along with your perl version I'll try to replicate and diagnose further.

Replies are listed 'Best First'.
Re^4: Imager::File::TIFF Dependencies
by BrentD (Sexton) on May 23, 2017 at 16:17 UTC
    Here's a stripped down version of the program that demonstrates the problem:
    #!/usr/bin/perl use strict; use warnings; use File::Path; use Imager; use Imager::Font::W32; use Imager::File::TIFF; use Carp 'verbose'; my $filename = "c:\\temp\\test\\errtest.tif"; my $white = Imager::Color->new(255, 255, 255); my $black = Imager::Color->new(0,0,0); my $xres = 240; #Horizontal Resolution (in DPI) of image my $yres = 240; #Vertical Resolution (in DPI) of image my $PageWidth = 8.5; my $PageHeight = 11; #-- End Paramaters --# my $xsize = $xres * $PageWidth; # Horizontal Page Size (Resolution * I +nches) my $ysize = $yres * $PageHeight; # Vertical Page Size (Resolution * I +nches) my $img = Imager->new(xsize=>$xsize,ysize=>$ysize); $img->settag(name =>'i_xres',value => $xres, name =>'i_yres',value => $yres, name =>'tiff_resolutionunit', value => 2); # Set the reso +lution unit to DPI # Load up Windows Font Face my $Font_Arial_Bold = Imager::Font->new(face => 'Arial Bold') or carp( +"Cannot load 'Arial Bold: ".Imager->errstr); $img->box(filled=>1, color=>$white); #Give our new page a white backgr +ound $Font_Arial_Bold->align(string => 'Test', size => 80, color =>$black, x => $img->getwidth/2, y => 250, halign => 'center', valign => 'center', image => $img); my $bilevel = $img->to_paletted(make_colors => 'mono', translate => 'errdiff', errdiff => 'stucki'); $bilevel->write(file => $filename, type => 'tiff', i_xres=> $xres, i_yres=> $yres, tiff_compression => 4);
    And here is the command I packaged it with:
    C:\Source_Repos\TestProg>pp -x -o test9.exe errtest.pl
    Then I moved it over to another machine (A Virtual Box running Windows 10 64-bit) and ran it:
    E:\>test9.exe Can't load 'C:\Users\generic\AppData\Local\Temp\par-67656e65726963\cac +he-b66580b6b26e48c9cb784308c1d0849bb7b17192\c6dc6748.xs.dll' for modu +le Imager::File::TIFF: load_file:The specified module could not be fo +und at C:/Strawberry/perl/lib/DynaLoader.pm line 193. at C:/Strawberry/perl/vendor/lib/PAR/Heavy.pm line 120. BEGIN failed--compilation aborted at Imager/File/TIFF.pm line 11. Compilation failed in require at script/errtest.pl line 7. BEGIN failed--compilation aborted at script/errtest.pl line 7. E:\>
    I am fairly positive that the file it's asking about, c6dc6748.xs.dll is actually C:\Strawberry\perl\vendor\lib\auto\Imager\File\TIFF\TIFF.xs.dll, as that c6dc6748 is the CRC32 of the TIFF.xs.dll in the compressed archive file (as opened in WinRAR by changing the .exe to a .zip). Here's my perl version info:
    C:\Source_Repos\TestProg>perl -V Summary of my perl5 (revision 5 version 24 subversion 0) configuration +: Platform: osname=MSWin32, osvers=6.3, archname=MSWin32-x64-multi-thread uname='Win32 strawberry-perl 5.24.0.1 #1 Tue May 10 21:30:49 2016 +x64' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define use64bitint=define, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL +_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fwrapv + -fno-strict-aliasing -mms-bitfields', optimize='-s -O2', cppflags='-DWIN32' ccversion='', gccversion='4.9.2', gccosandvers='' intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678 +, doublekind=3 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=1 +6, longdblkind=3 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='lo +ng long', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='g++', ldflags ='-s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~ +1\c\lib"' libpth=C:\STRAWB~1\c\lib C:\STRAWB~1\c\x86_64-w64-mingw32\lib C:\S +TRAWB~1\c\lib\gcc\x86_64-w64-mingw32\4.9.2 libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 +-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -l +mpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdl +g32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_3 +2 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 libc=, so=dll, useshrplib=true, libperl=libperl524.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=xs.dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-mdll -s -L"C:\STRAWB~1\perl\lib\CORE" +-L"C:\STRAWB~1\c\lib"' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY PERLIO_LAYERS PERL_COPY_ON_WRITE PERL_DONT_CREATE_GVSV PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PERL_PRESERVE_IVUV USE_64_BIT +_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_PERLIO USE_PERL_ATOF Built under MSWin32 Compiled at May 10 2016 21:42:01 @INC: C:/Strawberry/perl/site/lib C:/Strawberry/perl/vendor/lib C:/Strawberry/perl/lib . C:\Source_Repos\TestProg>
    and again, pp -V with extraneous info removed:
    C:\Source_Repos\TestProg>pp -V PAR Packager, version 1.035 (PAR version 1.010) Copyright 2002-2009 by Audrey Tang <cpan@audreyt.org> C:\Source_Repos\TestProg>

      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.

        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

Re^4: Imager::File::TIFF Dependencies
by swl (Prior) on May 23, 2017 at 11:52 UTC

    The version of pp you are using would also help.

    pp -V
      C:\Source_Repos\TestProg>pp -V PAR Packager, version 1.035 (PAR version 1.010)