Arch Linux User Repository

misc: There's no "must". Trusted users do as they please. Personally I consider Arch a shared-libs-based distro so I won't waste time and space packaging static libs. (It's bad enough that common code is duplicated four times between mujstest, mupdf, muraster, and mutool.)

Seems the entire libmupdf stuff now must be packaged separately, as community does:
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/mupdf

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.

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 :-).

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.

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.

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.

Hi vesath - Thanks for the reply, I really appreciate your comment. I'm current using llpp-git package and the current maintainer (drrossum) suggested (https://aur.archlinux.org/packages/llpp-git/?comments=all) 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 http://git.ghostscript.com/mujs.git, 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.

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.

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().
Aborting...

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