In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
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>
