1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
Here is a hopefully informative mini-rant about shared library support
for mupdf.
Upstream doesn't do shared libraries and doesn't recommend distro
packages use them. This build used to follow that advice. However,
mupdf is just too large to use as a static library. We end up with a
47MB libmupdf.a, plus 7 33MB binaries. *Every* distro I've looked at
ships mupdf as shared libs, despite upstream's policy.
A long time ago (in 2013), I used to patch mupdf for shared lib support,
but I removed it when it stopped applying cleanly. Thomas Morper on the
slackbuilds-users mailing list recently (2018) asked if I could include
a patch (from LFS) that adds shared library support, so starting with
mupdf 1.13.0, BUILD 2, we have shared libraries again.
In case someone *really* disagrees with this change, I added a STATIC=yes
environment setting. If you use this, you get static libs and no
shared ones, per upstream's policy. This has been tested and works for
1.13.0-2, but be aware that I probably won't be testing static builds
for every mupdf release. If you run into trouble, email me and/or the
slackbuilds-users list.
The library versioning scheme I had to use is unfortunate. The major
soname version is supposed to only change when there's an incompatible ABI
change. The way I'm doing it, it changes for every mupdf release [*]. This
is because upstream doesn't tell us when the ABI changes, because it's
not relevant for them. They support only static libs specifically to
avoid the headache of having to track and minimize ABI changes. Whenever
they want to change the ABI, they just do it. Anything built against the
old version will keep working fine, because it's statically linked. With
shared libs, I have to invent my own library versioning scheme.
The end result of this is, I (humble packager) can't easily tell when
the ABI has changed, so I treat every release [*] as an ABI change. Means
anything linked with libmupdf will fail with 'cannot open shared object
file' after a mupdf upgrade, so it'll have to be rebuilt. The alternative
would be to use unversioned shared libs, which would (seem to) avoid
the need to rebuild... but whenever the undocumented ABI changed, we'd
get weird behaviour and segfaults instead of a clean error message.
The shared library patch used here is by me (B. Watson), based on a
patch from Linux From Scratch. The original LFS patch doesn't include
versioned libs, I suspect becase in LFS you tend to upgrade the entire
OS by rebuilding it, instead of upgrading just one library.
Right now, the only SBo builds affected by mupdf upgrades will be
zathura-pdf-mupdf and possibly fbpdf (if built with optional mupdf
support). Both have been tested with shared mupdf, and both compile and
run cleanly.
[*] Actually, not micro-version point releases (e.g. 1.13.0 => 1.13.1).
Hopefully this doesn't cause a problem later. Upstream has just
switched to a major.minor.micro version scheme starting with 1.13.0,
so I don't know how often there will be micro-version bumps, and
whether or not they'll have ABI changes.
|
