Package Details: llpp-git 31.r24.gc79a0b8-1

Git Clone URL: (read-only, click to copy)
Package Base: llpp-git
Description: A graphical PDF viewer which aims to superficially resemble less(1).
Upstream URL:
Licenses: custom
Conflicts: llpp
Provides: llpp
Submitter: mfwitten
Maintainer: aksr
Last Packager: aksr
Votes: 61
Popularity: 0.78
First Submitted: 2010-10-26 22:21
Last Updated: 2020-03-18 06:05

Dependencies (37)

Required by (0)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 ... Next › Last »

hero commented on 2017-04-11 21:16

libmupdf version 1.11 just came out. With that version the current head compiles again. This is what I did to make it compile: I do not know if other modifications make it even better, but it might be a starting point for you to update the package.


menta commented on 2016-12-15 18:14

Here is an updated PKGBUILD:

It contains new dependencies and optional dependencies, modifications to avoid build errors, and new packaging instructions.

A note about (optional) dependencies: file, gzip, and bzip2 are members of the base group, which is assumed to be installed on all Arch Linux systems, so these packages shouldn't be listed in the *depends arrays:

drrossum commented on 2016-07-06 07:09

The newest llpp revisions seem to be incompatible with the current mupdf library. The llpp package does still work.

loserMcloser commented on 2016-07-05 16:39

Build fails, I guess mupdf package removed include files?

+ ocamlc.opt -ccopt '-I /usr/include/freetype2 -Wextra -Wall -Werror -D_GNU_SOURCE -O -g -std=c99 -pedantic-errors -Wunused-parameter -Wsign-compare -Wshadow -o build//link.o' -c ./link.c
./link.c:43:24: fatal error: mupdf/fitz.h: No such file or directory
#include <mupdf/fitz.h>

jooch commented on 2016-01-30 00:50

Unable to build this:

+ ocamlc.opt -ccopt '-I /usr/include/freetype2 -Wextra -Wall -Werror -D_GNU_SOURCE -O -g -std=c99 -pedantic-errors -Wunused-parameter -Wsign-compare -Wshadow -o build//link.o' -c ./link.c
./link.c:198:5: fout: unknown type name ‘fz_stext_page’
fz_stext_page *text;

tutu commented on 2016-01-12 02:42

Hi drrossum - Thanks for getting back to me. I agree with you about the haskell dependency, no need to include while not necessary.

I tried the package build and it works if mupdf-git is installed, and it does not when mupdf is installed instead. I think this is expected till the maintainer of mupdf release a new version.

Thanks for the help. Hopefully other people interested in llpp-git will be able to do it now.

drrossum commented on 2016-01-11 17:29

Hi tutu,
Thank you for the helpful comments on patching the script for the recent changes in mupdf libraries. I pushed an updated PKGBUILD that includes your patches.

I use haskell myself, but many users will not appreciate the large build dependency this would pull in. So I don't want to use it in the PKGBUILD.

I included openjpeg2 as explicit dependency so that we don't depend on the mupdf-git configuration for building llpp-git.

The newest PKGBUILD works for me, but please let me know if you run into issues.

tutu commented on 2016-01-10 04:16

Hi drrossum - Thanks for advising mupdf-git. I tried out the package and it seems to work. There is a caveat though, the developers of mupdf are not providing third-party libraries anymore. Now, besides libmupdf.a, they create another static lib (libmupdfthird.a) that contains the routines of the third-party libs (eg, libmujs, openjpeg, etc) that llpp utilizes.

The build script that llpp-git PKGBUILD uses ( was not synced by llpp developers, they only updated Shakefile.hs. I got in contact with llpp developer on Github and I was surprised how fast I got a reply. Now the script works if you clone the llpp and mupdf repositories the way they describe in BUILDING file (the easy way, as they say).

To build using PKGBUILD I had to change

sed -i -e 's+-lopenjpeg+-lopenjp2+'


sed -i -e 's+-lmupdfthird+-lmupdfthird -lz -lfreetype -ljpeg -ljbig2dec+'

When building mupdf, you can choose which third party libs will be build as a git submodule, linking them statically to libmupdfthird.a. In mupdf-git there are two third-party git submodules current being initialized, openjpeg and mujs, hence they did not being linked explicitly on the line above anymore.

I would like to ask some questions:

1. The way I changed the PKGBUILD file, I had to know which libraries were linked statically in mupdf. Is there anyway to know this with out looking the PKGBUILD of mupdf-git?

2. What is your opinion on Shakefile.hs vs

3. Is it better to initialize all the git submodules and link the third-party libs statically to libmupdfthird.a?

Thanks again for your time and help.

drrossum commented on 2016-01-04 17:23

Thanks for the comment. Using mupdf-git seems the way to go for llpp-git.

tutu commented on 2016-01-04 07:34

Is anyone else having issues in building the latest version of llpp using this PKGBUILD? I'm having some linking problems, eg, some routines names are not being recognize, like fz_drop_stext_page from mupdf libs.

I download llpp repo directly from its git repository and also and also clone the latest version from mupdf. After build mupdf, script from llpp worked fine.

Should we just wait for the update of mupdf?