Legacy ImageMagick Discussions Archive

It's because jpeg 9 removed those defines.

Thanks, 6.8.9-1 builds fine with jpeg2.

The MacPorts maintainer of openjpeg has updated it to version 2.1.0, which now supplies the pkg-config file ImageMagick expects to find, so it's detected fine. Unfortunately, it does not compile: coders/jp2.c:343:44: error: too few arguments to function call, expected 3, have 2 opj_stream_set_user ...

I am the maintainer of ImageMagick in MacPorts, but I was only informed of this problem today. If nobody reports problems to me, it's quite possible I won't know about the problem and therefore won't be working on fixing it, so please report MacPorts issues in the MacPorts issue tracker when you ...

jonasjonas wrote:Is this just a setting in the portfile?

Yes. I've fixed it while updating the port to 6.8.7-3.

Aha. ImageMagick apparently requires .la files.

In MacPorts, as of Mavericks, we delete .la files by default, because they are usually useless. But if ImageMagick needs them, we can retain them for ImageMagick.

Then as I said this is a step backward from 6.8.0-7 where this was not necessary. In MacPorts, ImageMagick is a completely separate package from PerlMagick, and we like it that way. Users who want PerlMagick can install it (e.g. "sudo port install p5.12-perlmagick"), which will automatically install ...

Add --with-perl to your configure script. Does the PerlMagick install work now? And compile with make all perl-build I too want to know the best way to build perlmagick, and I don't want to have to run "./configure" or "make all" to do so. Neither of those steps were required for 6.8.0-7, the most ...

It sounds like I need to completely rethink how we package ImageMagick in MacPorts. Currently we have one port that contains everything. It sounds like I need to split the libraries and headers off into their own libMagick port. Then I could easily make four ports, one for each available library ...

Ok so that proves that the scenarios I mentioned above would be a problem, and indeed are probably a problem in MacPorts already, we just haven't noticed before. As I understand it, the 4 permutations of library name decoration are Q8, Q16, Q16HDRI, and Q32. How would I build and install all four ...

Thanks, and I see from configure.ac that it is only the pixel quantum and the HDRI option that change the library name suffix. I can try your suggestion of changing MAGICK_ABI_SUFFIX to a constant value not affected by compile options. But why was a suffix added to the library name if there is no ...

Hello, I'm the maintainer of ImageMagick in the MacPorts OS X package management system , and I need packaging advice. As announced , the ImageMagick library names now come decorated with the pixel quantum, i.e. what used to be libMagick++.6.dylib, libMagickCore.6.dylib and libMagickWand.6.dylib on ...

It seems that ImageMagick assumes that if any data is available to read, then at least 8192 bytes will be available to read, which is not necessarily the case if a program is producing the PNG data slowly. To isolate the problem away from the vncsnapshot program, I turned to the slowcat python ...

Hello, I'm encountering what seems like a bug in ImageMagick 6.8.0-1, which is running on OS X 10.8.2 Mountain Lion and was compiled with Apple clang version 4.1 (tags/Apple/clang-421.11.65) (based on LLVM 3.1svn). I'm using vncsnapshot-png which outputs a PNG file to stdout. (In fact, that code as ...

Check wand/magick-image.c and look for MagickSetImageEndian(). It should be there. Yes it is, as is MagickGetImageEndian(). If so, perhaps MagickWand for PHP is not linking against that version of the ImageMagick MagickWand library. There is no other version installed. The problem remains using ...