Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Although I have libfpx installed, I don't want IM to use it, because the library is incredibly buggy -- especially on 64-bit platforms.
So I specify ``--without-fpx'' to IM's configure.
Apparently, FPX support is nonetheless compiled in, and the regression tests (make check) try to test the FPX code leading to spectacular crashes. Here is my build log.
Here are my questions:
How to reliably turn FPX support off from both the binaries and the regression tests?
Why was not this problem discovered, when running regression tests on 64-bit RedHat?
FPX works fine for us on 64-bit Redhat. ImageMagick does not include FPX support by default. Run
./configure
and check the last 40 or so lines of output. It should say that FPX was not included. From your build log it looks like there are FreeBSD patches against ImageMagick. Its possible one of the patches is enabling FPX support. Since we did not write the patches we can't help you.
Unfortunately, you can also see regression tests trying (and failing) to use FPX -- just use your browser's search functionality to find the strings "FPX" throughout the logfile. For example:
I just downloaded the "released" version of 6.3.5-3 (not from beta/) and tried building and running `make check' again.
The result: 133 of 696 tests failed. The build and test log is now updated with these results.
All of the failures are segmentation faults, and many (though not all) of them are related to FPX, which is being explicitly disabled by a configure-argument.
Still awaiting a link to the log of `make check' on a RedHat/amd64 system. I do not believe, things are smooth over there either...
Core was generated by `rwfile'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000804008cc0 in ?? ()
(gdb) where
#0 0x0000000804008cc0 in ?? ()
#1 0x00000008020079e2 in __cxa_finalize () from /lib/libc.so.6
#2 0x0000000802007637 in exit () from /lib/libc.so.6
#3 0x0000000000401085 in _start ()
(gdb) quit
Ok, this is "easily" overcome by disabling module support. Something is wrong with the dynamic module-loading -- I observed a similar problem on FreeBSD/i386 too.
We noticed that one of librsvg dependancies causes the segmentation fault. It has an improper signal handler or atexit() handler (we're guessing). You can fix the problem by adding --without-rsvg to your configure script command line. SVG will still convert but it will use the internal ImageMagick SVG render engine.
We eliminated atexit() in Magick++ as you suggested. We also patched the configure script so you must explicitly enable Jasper to include it in a built-- at least until the Jasper distribution is patched to avoid the dlclose faults.