Skip to content

Comments

ghostscript: use system-wide openjpeg#169575

Merged
SuperSandro2000 merged 1 commit intoNixOS:stagingfrom
Ma27:ghostscript-openjpeg
Apr 25, 2022
Merged

ghostscript: use system-wide openjpeg#169575
SuperSandro2000 merged 1 commit intoNixOS:stagingfrom
Ma27:ghostscript-openjpeg

Conversation

@Ma27
Copy link
Member

@Ma27 Ma27 commented Apr 21, 2022

Description of changes

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] https://github.com/archlinux/svntogit-packages/blob/bafcb5473b59d5386dd110d1cb249372dce9ea6c/trunk/PKGBUILD#L50
[2] https://src.fedoraproject.org/rpms/ghostscript/blob/e4eec13ab6ace2bad64b740d352964bbf61d1aa7/f/ghostscript.spec#_245

Things done
  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 22.05 Release Notes (or backporting 21.11 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
    • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
  • Fits CONTRIBUTING.md.

@Ma27 Ma27 requested a review from calbrecht April 21, 2022 12:10
@Ma27
Copy link
Member Author

Ma27 commented Apr 21, 2022

After taking a closer look it seems to me as if ghostscript's openjpeg is just a stripped down version of upstream these days.

@ofborg ofborg bot requested a review from viric April 21, 2022 12:27
@ofborg ofborg bot added 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 501-1000 This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 1001-2500 This PR causes many rebuilds on Linux and should target the staging branches. labels Apr 21, 2022
@SuperSandro2000
Copy link
Member

needs to target staging

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:

    NixOS#8  0x00007f78c79ad2f5 in MagickSignalHandler.cold () from /nix/store/bqy80qiw6czqh7vsmmmivwdswp9zzjgl-imagemagick-7.1.0-29/lib/libMagickCore-7.Q16HDRI.so.10
    NixOS#9  <signal handler called>
    NixOS#10 0x00007f78c5a6095f in opj_malloc () from /nix/store/wg6ly83k1k1fjiygiv1jr7li3p6dwsvq-ghostscript-with-X-9.55.0/lib/libgs.so.9
    NixOS#11 0x00007f78c5a60981 in opj_calloc () from /nix/store/wg6ly83k1k1fjiygiv1jr7li3p6dwsvq-ghostscript-with-X-9.55.0/lib/libgs.so.9
    NixOS#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] https://github.com/archlinux/svntogit-packages/blob/bafcb5473b59d5386dd110d1cb249372dce9ea6c/trunk/PKGBUILD#L50
[2] https://src.fedoraproject.org/rpms/ghostscript/blob/e4eec13ab6ace2bad64b740d352964bbf61d1aa7/f/ghostscript.spec#_245
@Ma27 Ma27 force-pushed the ghostscript-openjpeg branch from 89556af to d921815 Compare April 22, 2022 23:14
@Ma27 Ma27 changed the base branch from master to staging April 22, 2022 23:15
@Ma27
Copy link
Member Author

Ma27 commented Apr 22, 2022

Done @SuperSandro2000

@SuperSandro2000 SuperSandro2000 merged commit 33d1f7c into NixOS:staging Apr 25, 2022
@Ma27 Ma27 deleted the ghostscript-openjpeg branch April 25, 2022 05:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

10.rebuild-darwin: 501-1000 This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 1001-2500 This PR causes many rebuilds on Linux and should target the staging branches.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants