Package Details: mupdf-git 20161005.87524fa-1

Git Clone URL: (read-only)
Package Base: mupdf-git
Description: Lightweight PDF, XPS and CBZ viewer
Upstream URL:
Licenses: AGPL3
Conflicts: mupdf
Provides: mupdf
Submitter: None
Maintainer: vesath
Last Packager: vesath
Votes: 14
Popularity: 0.685246
First Submitted: 2011-03-07 21:49
Last Updated: 2016-10-05 23:50

Required by (13)

Sources (2)

Latest Comments

misc commented on 2016-10-06 17:32

Seems the entire libmupdf stuff now must be packaged separately, as community does:

vesath commented on 2016-07-09 17:17

For a while the ever-increasing size of this package has been a real annoyance to me. It's a direct consequence of upstream's static-linking policy: common code and fonts are embedded into each individual binary. Ideally they would be built into a shared library which individual binaries would link against. However that's not trivial to achieve in our modest PKGBUILD. So in the meantime I tried to keep the package size under control with two slightly controversial tweaks:
- static libraries are no longer provided
- CJK fonts are no longer embedded

I believe this keeps this package fit for nearly everyone's purpose and it brings its size down from 176 MB to 44 MB. Feel free to voice any concerns you might have, together with suggestions on alternative ways to keep this package manageable. Cheers.

tutu commented on 2016-01-10 17:16

vesath: Thanks for the info about how to deal with libs. It is very nice to be able to talk to someone that have more experience on the topic. I will study a bit about how to construct a package in AUR and perhaps create a mujs package :-).

vesath commented on 2016-01-10 07:02

tutu: If your own project is unrelated to mupdf, there is really no reason for you to depend on the specific versions of mujs (or any other library) that mupdf requires and bundles into its libmupdfthird.a; you should simply use upstream mujs.

Last time I checked, mupdf could not be built against our shared openjpeg system libraries that our openjpeg package provides, indeed because it relies on yet unreleased openjpeg features. Of course I will compile against system libs whenever possible: the Arch way teaches us to avoid compiling libraries statically.

Regarding zlib, it is not explicitely included in the packages dependencies because it is already indirectly included as a dependency of pretty much everything: freetype2 depends on it, jbig2dec depends on libpng which depends on it, etc.

tutu commented on 2016-01-10 00:41

Hello again vesath - Thanks for the explanation, it was really helpful.

I noticed that you listed freetype2, jbig2dec, libjpeg and libxext as dependencies. Aren't zlib and the dependencies currently in mupdf Arch package supposed to be added as well? Some of those libraries are listed in the README file from mupdf and are not present in the PKGBUILD. Here is a quick summary of mupdf README and the dependencies:

- dependencies: freetype2, jbig2dec, libjpeg, openjpeg, zlib
- optional:
# Command line tools (HAVE_X11=yes/no): xorg-dev
# OpenGL-based viewer (HAVE_GLFW=yes/no): mesa-common-dev, libgl1-mesa-dev, xorg-dev, libxcursor-dev, libxrandr-dev, libxinerama-dev.

The reason why I needed libmujs.a has actually been solved. The developers of mupdf are basically creating a static library called libmupdfthird.a with the third-party libs (mujs, openjpeg, etc). Since you are initializing the mujs git submodule, the routines I need are static linked to libmupdfthird.a. The same thing happen to openjpeg.

Since Arch does have a package to openjpeg2 I tried to remove the line that active the submodule for openjpeg, however I had some compilation issues (some function were missing arguments - I think mupdf uses the most up to date version).

I wonder if we could skip the initialization of openjpeg git submodule when a new stable release of openjpeg2 is available in the Arch package repository. What do you think?

Thanks again.

vesath commented on 2016-01-09 08:18

tutu: Yes! Like openjpeg and jbig2dec, mujs is a separate project and should be packaged separately. It probably is a dependency of nothing but mupdf, still it was wrong of me to ship its libraries (static or otherwise) with mupdf.

Concerning Arch's policy, there is a consensus to avoid static libs whenever possible, though they are tolerated when there is no dynamic counterpart. Nothing more. Of course a mujs or mujs-git package in the AUR would be a very welcome addition.

tutu commented on 2016-01-09 05:58

Hi vesath - Thanks for the reply, I really appreciate your comment. I'm current using llpp-git package and the current maintainer (drrossum) suggested ( to switch the required dependency from mupdf to mupdf-git. llpp uses most up to date mupdf libs and other third party libs, such as, mujs.

Do you think it would be wise in creating a package in AUR for mujs to address this issue? The have mujs source here, so, perhaps one could create a mujs-git? Or this is not recommend by Arch community?

Thanks for the advice about `make install-nacl-libs`. I will do some research and see if solves my problem. Thanks again.

vesath commented on 2016-01-08 08:30

It appears upstream does not build third-party static libraries by default anymore. Those who want it can do `make install-nacl-libs` but I have no interest in doing that for this package: Arch has repeatedly discouraged the use of static libraries.

tutu commented on 2016-01-07 05:57

Hi there - I'm having issues in building the PKGBUILD.

install: cannot stat ‘build/release/libmujs.a’: No such file or directory
==> ERROR: A failure occurred in package().

Apparently libmujs.a is not being created anymore. Did the name of it changed or PKGBUILD is not build mupdf correctly?

vesath commented on 2014-07-27 22:10

Oh, well, okay. I forgot that mupdf does not ship dynamic libraries... My mistake. Should be fixed now. Thanks for the report.

All comments