Bug 232902 - graphics/mupdf: automatically pick libmupdfthird.so
Summary: graphics/mupdf: automatically pick libmupdfthird.so
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Alexandre C. Guimarães
Depends on: 233727
  Show dependency treegraph
Reported: 2018-11-02 06:55 UTC by Eygene Ryabinkin
Modified: 2019-02-19 22:26 UTC (History)
2 users (show)

See Also:
uzsolt: maintainer-feedback+

Patch for graphics/mupdf (2.13 KB, patch)
2018-11-02 06:55 UTC, Eygene Ryabinkin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eygene Ryabinkin freebsd_committer 2018-11-02 06:55:41 UTC
Created attachment 198879 [details]
Patch for graphics/mupdf

Had upgraded Zathura and MuPDF on my -CURRENT box recently to
$ pkg query %n-%v | egrep '(mupdf|zathura)'
and found out that Zathura was not able to open PDF files any more.
Quick digging found out that libmupdf.so.1.13.0 wanted symbol
'cmsGetContextUserData', but it wasn't available.  This symbol
is provided by the lcms2 that is bundled with MuPDF, but goes
to libmupdfthird.so.1.13.0.  And fitz code from
./source/fitz/color-lcms.c wants that one (unless NO_ICC is defined
via Makethird file, but it isn't because lcms2 is bundled to the
thirdparty/ folder and Makethird checks exactly that when branches
and decides /not/ to engage NO_ICC).

I am slightly puzzled that previous version had no such problems --
no visible changes in FreeBSD port (Makefile/patches), but I hadn't
yet seen the source code of the previous MuPDF version.

The code builds fine on -CURRENT, I had contacted the maintainer, Zsolt Udvari <uzsolt@uzsolt.hu>, and have his blessing.

The patch is attached and I am willing to commit it.  Having hit by Grim Reaper, I need a review from one of the port committers.