in reply to Image::Magick - Exception 435: unable to open file `Image::Magick::Q16' @ error/Q16.xs/XS_Image__Magick__Q16_Read/13529

My starting point would always be to (try to) get a stack trace, by inserting something like the following before the call that dies:

use Carp;
local $SIG{__DIE__} = sub { Carp::confess(@_) };

[download]

That would give additional diagnostic information to help you or others figure out what's going on.

It isn't clear exactly what is happening when you run the script though - does it die with the error message in the title, or does it reach your print "Error b: $err\n"; line? It would also be useful to know the version numbers for perl and for Image::Magick - I assume something getting upgraded is what introduced the problem.

Searching around a bit, there appear to be two distinct versions of the Image::Magick module: one provided on CPAN (currently at version 7.1.0-0), another provided as a stub as part of the ImageMagick library distribution (on github here). The filename in your error message suggests you are using the library distribution, which may make it a bit harder to diagnose.

  • Comment on Re: Image::Magick - Exception 435: unable to open file `Image::Magick::Q16' @ error/Q16.xs/XS_Image__Magick__Q16_Read/13529
  • Select or Download Code

Replies are listed 'Best First'.
Re^2: Image::Magick - Exception 435: unable to open file `Image::Magick::Q16' @ error/Q16.xs/XS_Image__Magick__Q16_Read/13529
by mldvx4 (Hermit) on Jun 06, 2023 at 14:22 UTC

    Thanks.

    Yes the script gets to the print "Error b: $err\n"; line, which shows the output:

    Error b: Exception 435: unable to open file `Image::Magick::Q16' @ error/Q16.xs/XS_Image__Magick__Q16_Read/13529

    That's even after adding the CARP lines to the beginning of the script as you've recommended. So adding CARP provides no additional output.

    On the one system, 

    $ apt-cache policy libimage-magick-perl | head -n 3
libimage-magick-perl:
  Installed: 8:6.9.11.60+dfsg-1.3ubuntu0.22.04.3
  Candidate: 8:6.9.11.60+dfsg-1.3ubuntu0.22.04.3

$ apt-cache policy perl | head -n 3
perl:
  Installed: 5.34.0-3ubuntu1.2
  Candidate: 5.34.0-3ubuntu1.2

    [download]

    On the other system, 

    $ apk list imagemagick-perlmagick
imagemagick-perlmagick-7.1.1.11-r3 x86_64 {imagemagick} (ImageMagick) 
+[installed]

$ apk  list | grep ^perl-5
perl-5.36.1-r2 x86_64 {perl} (Artistic-Perl OR GPL-1.0-or-later) [inst
+alled]

    [download]
    Edit: updated with Perl versions
[reply]
[d/l]
[select]

      Hmm, I had a little dig, and I'm not getting very far: the internal structure of the code is, um, unusual. You are probably best off opening an issue on github, but be warned that the maintainers are a small team that appear to be somewhat swamped.

      I note that you have not mentioned the version of perl: they will likely want that alongside the other version numbers you have mentioned.

[reply]

        Thanks. After starting to check some semi-random things, I found that once I added imagemagick-svg and imagemagick-webp to that system the script resumed working. So, at the end of the day, the problem had nothing to do with Perl except that the symptoms of some change manifested via well-used Perl script on a production system which has only received system updates of late. Unfortunately I have no clue as to what or why there were changes inside those updates which set the script off its rails.

        tldr; solved but dunno the original cause

[reply]

In Section Seekers of Perl Wisdom