[Bug 216823] graphics/mupdf: Build shared libraries

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216823

            Bug ID: 216823
           Summary: graphics/mupdf: Build shared libraries
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Keywords: patch
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: freebsd-ports-bugs at FreeBSD.org
          Reporter: t at tobik.me
                CC: udvzsolt at gmail.com
 Attachment #179642 maintainer-approval?(udvzsolt at gmail.com)
             Flags:
             Flags: maintainer-feedback?(udvzsolt at gmail.com)
                CC: udvzsolt at gmail.com

Created attachment 179642
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=179642&action=edit
libmupdf.diff

Hi,

would it be okay if we switched graphics/mupdf to build shared
libraries instead of static ones?

It requires minor changes to the port and the immediate benefits are:

- Drastic installed size reduction:
  llpp-25_1                      34.3 MiB -> 1022 KiB
  mupdf-1.10.a,2                 285 MiB -> 42.8 MiB
  zathura-pdf-mupdf-0.3.1_1      33.4 MiB -> 26.0 KiB
- For security fixes we won't need to bump llpp's and zathura-pdf-mupdf's
  PORTREVISION anymore
- No need to build mupdf twice anymore (once with -fPIC and once without)

Open questions:

The idea comes from OpenBSD's textproc/mupdf port and they manually
increase the lib's major with every port update.  Since mupdf doesn't
guarantee ABI compatibility and breaks it with every release, I think
we'd need to do the same.  My first idea was to set libraries major to
a value based on the port version (for 1.10a the library's soname
would be libmupdf.so.110.0), but I think OpenBSD's way might be better
in the long run.

FreeBSD 11.0/amd64 test logs: https://pkg.tobik.me/logs/libmupdf/
Portlint: ok

-- 
You are receiving this mail because:
You are the assignee for the bug.