The following error occurs when using `imagemagickBig`:
$ ./result/bin/identify sample.jp2
[1] 699089 IOT instruction (core dumped) ./result/bin/identify sample.jp2
When looking at the call-trace it seems as if certain symbols, e.g.
`opj_malloc` are mixed up:
#8 0x00007f78c79ad2f5 in MagickSignalHandler.cold () from /nix/store/bqy80qiw6czqh7vsmmmivwdswp9zzjgl-imagemagick-7.1.0-29/lib/libMagickCore-7.Q16HDRI.so.10
#9 <signal handler called>
#10 0x00007f78c5a6095f in opj_malloc () from /nix/store/wg6ly83k1k1fjiygiv1jr7li3p6dwsvq-ghostscript-with-X-9.55.0/lib/libgs.so.9
#11 0x00007f78c5a60981 in opj_calloc () from /nix/store/wg6ly83k1k1fjiygiv1jr7li3p6dwsvq-ghostscript-with-X-9.55.0/lib/libgs.so.9
#12 0x00007f78c4f48e24 in opj_create_decompress () from /nix/store/qwalb0kjz1p9c4j48qkk6ql47ds2lnhh-openjpeg-2.4.0/lib/libopenjp2.so.7
The `opj_create_decompress()` is called from the `openjpeg`-integration
of `imagemagick` and thus shouldn't affect `ghostscript` at all.
However, `ghostscript` (`libgs.so` to be precise) also exposes e.g.
`opj_malloc`:
$ objdump -t /nix/store/wg6ly83k1k1fjiygiv1jr7li3p6dwsvq-ghostscript-with-X-9.55.0/lib/libgs.so.9.55|grep opj_malloc
0000000000205940 g F .text 000000000000002b opj_malloc
Because of that, two incompatible symbols are used in the same process
and thus the `identify`-call breaks because the wrong one is used. To
work around that I decided to use the system-wide openjpeg instead.
I'm not sure why `libgs.so` wants to expose these symbols anyways, but
with that workaround the problem is solved.
Even though it's mentioned that ghostscript's openjpeg is heavily
patched, I think that this is somewhat outdated or at least irrelevant
considering that both ArchLinux[1] and Fedora[2] use the system-wide
`openjpeg` instead.
[1] bafcb5473b/trunk/PKGBUILD (L50)
[2] e4eec13ab6/f/ghostscript.spec (_245)
upon closer inspection, `make check` does little except rebuild
everything with some different options. ghostscript has a python-based
test suite, but it looks like an unmaintained disaster zone.
so the best we can probably do for now is ensure we can render all the
provided examples.
Dynamic library name on Darwin contains only 'maj.min' eg "9.53";
the build however used $version to set rpath;
this broke on 2029ca37 when $version went from "9.52" to "9.53.3".
Add a call to 'gs' in installCheckPhase,
to break the build if dylib issues arise in the future.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
Co-authored-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
This is tagged as version 9.26a in the ghostpdl repo, but unfortunately
there are no tarballs released with that version number so far. We'll
continue calling this version 9.26 for now for simplicity's sake (and we
can switch to 9.26a and remove the patch when it's properly released).
Fixes#58262Fixes#58089
GS ships with a fork of lcms2 ("lcms2mt"), but the ABI separation
between the fork and the original seems insufficient. If libgs is linked
alongside liblcms2 (for example, this is the case with imagemagick) then
it will call into the original library instead of the fork, causing
segfaults.
Follow the example of both Arch and Debian in this regard -- they both
use the systemwide lib instead of the fork.
