Package Details: llpp-git 25.r72.g6572184-1

Git Clone URL: (read-only)
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.000046
First Submitted: 2010-10-26 22:21
Last Updated: 2017-02-16 04:59

Dependencies (35)

Required by (0)

Sources (1)

Latest Comments

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?

tutu commented on 2015-10-30 03:19

Hi there - I notice that this package was recently updated and the installation was "successful". However, when I try to use the llpp I get the following error.

$ llpp
No bytecode file specified.

Did I miss something?
I checked for the required dependencies and it seems I have them all.

The command I use to install it was:

$ git clone
$ cd llpp-git
$ makepkg -sri

Thanks for the help.

PS: I really like this program. Have any of you guys able to make the forward or inverse search work with the highlight rectangle? I've seen this feature in SumatraPDF and it seems it is also present on llpp, but I was not able to make it work.

holos commented on 2015-09-28 15:54

Upstream has traded ninja for some Haskell-based build system. All this build system juggling is making maintaining this package very annoying.

rubenvb commented on 2015-04-28 08:46

I cannot build this due to the following makepkg errors:

==> Building and installing package
==> Making package: llpp-git 21.r61.gdf146ab-1 (Tue Apr 28 10:45:52 CEST 2015)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Cloning llpp git repo...
Cloning into bare repository '/tmp-yaourt/yaourt-tmp-ruben/aur-llpp-git/llpp'...
remote: Counting objects: 6294, done.
remote: Compressing objects: 100% (1999/1999), done.
remote: Total 6294 (delta 4277), reused 6291 (delta 4276)
Receiving objects: 100% (6294/6294), 1.49 MiB | 0 bytes/s, done.
Resolving deltas: 100% (4277/4277), done.
Checking connectivity... done.
-> Found fix-libs.patch
==> Validating source files with sha256sums...
llpp ... Skipped
fix-libs.patch ... Passed
==> Extracting sources...
-> Creating working copy of llpp git repo...
Cloning into 'llpp'...
==> Starting pkgver()...
==> Updated version: llpp-git 21.r63.g6686874-1
==> Starting prepare()...
patching file
patching file
==> Starting build()...
Configuration results are saved in /tmp-yaourt/yaourt-tmp-ruben/aur-llpp-git/src/llpp/.config
To build - type: ninja
[11/11] link /tmp-yaourt/yaourt-tmp-ruben/aur-llpp-git/src/llpp/build/llpp.custom
make: Entering directory '/tmp-yaourt/yaourt-tmp-ruben/aur-llpp-git/src/llpp/misc/completions'
wrote: bash/llpp
wrote: zsh/llpp
wrote: bash/llppac
wrote: zsh/llppac
make: Leaving directory '/tmp-yaourt/yaourt-tmp-ruben/aur-llpp-git/src/llpp/misc/completions'
==> Entering fakeroot environment...
==> Starting package()...
make: Entering directory '/tmp-yaourt/yaourt-tmp-ruben/aur-llpp-git/src/llpp/misc/completions'
install -d /tmp-yaourt/yaourt-tmp-ruben/aur-llpp-git/pkg/llpp-git/usr/share/bash-completion/completions
install -m644 bash/{llpp,llppac} \
install: cannot stat 'bash/{llpp,llppac}': No such file or directory
Makefile:15: recipe for target 'install' failed
make: *** [install] Error 1
make: Leaving directory '/tmp-yaourt/yaourt-tmp-ruben/aur-llpp-git/src/llpp/misc/completions'
==> ERROR: A failure occurred in package().
==> ERROR: Makepkg was unable to build llpp-git.

flu commented on 2015-04-22 10:49

It's failing here:

==> Starting build()... string not in pwd: build
==> ERROR: A failure occurred in build().

CjK commented on 2015-01-25 22:29

Same error for me, after building with makepkg or pacaur:

$ llpp my.pdf
llpp: error while loading shared libraries: /home/cjk/abs/local/llpp-git/src/llpp/build/ cannot open shared object file: No such file or directory

aksr commented on 2015-01-12 10:29

Hi, I'm getting this error:

windowsrefund commented on 2015-01-08 22:32

Attempted to run llpp after a recent yaourt install...

llpp: error while loading shared libraries: /tmp/yaourt-tmp-windowsrefund/aur-llpp-git/src/llpp/build/ cannot open shared object file: No such file or directory

holos commented on 2014-11-24 16:46

Should work now.

aksr commented on 2014-09-10 06:55

OCaml is updated.

holos commented on 2014-09-03 17:52

A current PKGBUILD:

The install file should be one for updating the desktop file database

llpp switched to ocaml 4.02, so this will not work until you have the new ocaml.

karol_007 commented on 2014-09-02 00:22

==> Updated version: llpp-git 1757.bb1ce65-1
==> Starting build()...
==> Cleaning ...
==> Compiling ...
sh: No such file or directory
==> ERROR: A failure occurred in build().

flu commented on 2014-08-17 17:25

llppac is not found. I found it in a another location:

install misc/llppac "$pkgdir"/usr/bin/llppac

stevenhoneyman commented on 2014-08-17 16:06

Please change the local clone to "llpp" instead of "repo" - comment below from 10 months ago asking the same.

mfwitten commented on 2013-12-26 10:55

How's that?

alxarch commented on 2013-12-25 09:52

Latest build on fresh installation requires glu also

darkxsun commented on 2013-10-16 15:26

This PKGBUILD is storing the local git clone in 'repo/', which conflicts with (e.g.) the repo package. It should probably store in (something like) 'llpp/' instead.

menta commented on 2013-08-13 13:58

Thank you for including llppac in the package. You may also include a .desktop file, see a draft here: The list of supported MIME types was generated with the following script:

By investigating the llppac script and running it on sample files I discovered additional optional dependencies:
'antiword: conversion of Microsoft Word (.doc) documents (option 2)'
'zip: handling of png and jpeg images'
'texlive-core: dvi conversion'

A minor comment: Members of the "base" and "base-devel" groups should not be included in makedepends array ( I think members of the "base" group are also meaningless in the optdepends array. To check those:
pacman -Qi file gzip bzip2 bash make gcc | grep -E "Name|Groups"

menta commented on 2013-07-23 09:42

Please package the llppac script as well. You may use the following lines for optdepends:
'xsel: Text selection'
'unoconv: conversion of office documents'
'imagemagick: image conversion'
'librsvg: svg conversion (option #1)'
'inkscape: svg conversion (option #2)'
'princexml: html conversion'
'ghostscript: ps, dvi and djvu conversion'
'djvulibre: djvu conversion'

More info:

Thank you in advance!

mfwitten commented on 2013-05-20 08:58

For some reason, I was no longer receiving notifications about comments. The PKGBUILD has now been updated as suggested.

Earnest commented on 2013-04-30 21:29

Updated PKGBUILD for pacman 4.1 ==>

Earnest commented on 2013-04-30 20:48

Updated and standard PKGBUILD:

Anonymous comment on 2013-02-01 12:53

PKGBUILD still needs MAKEFLAGS='-j1'

mutterschiff commented on 2012-10-02 06:27

I get this errors on the new pkgbuild:
Fatal error: cannot find file '../src/var2def'
Fatal error: cannot find file '../src/var2switch'
Fatal error: cannot find file '../src/var2def'
Fatal error: cannot find file '../src/var2switch'

zaza commented on 2012-10-01 13:35

Oh, I found it. My problem disappears after adding MAKEFLAGS='-j1' before bash

@@ -99,7 +99,7 @@
if [[ $_compile ]]; then

msg "Compiling ..."
- bash
+ MAKEFLAGS='-j1' bash


zaza commented on 2012-09-28 12:24

I have same problems with building on 32-bit system.

bernarcher commented on 2012-09-27 21:12

I tried again from scratch, downloaded the tarball and run makepkg directly on it. Unfortunately, same result. And, yes, var2def has the executable bit set.
This is on a x86_64 system. Could this be of any influence?

mfwitten commented on 2012-09-26 13:32

According to (, the common error `Cannot find the bytecode file' ocurrs when `The file that ocamlrun is trying to execute (e.g. the file given as first non-option argument to ocamlrun) either does not exist, or is not a valid executable bytecode file.'

I'm guessing the var2def is for some reason not a valid executable bytecode file. On my system, `var2def' has the executable bit set; does it on your systems?

mfwitten commented on 2012-09-26 13:28

Bizarre... However, I STILL can't reproduce it; I downloaded this package's tarball and ran `makepkg -sfi' without modifying the PKGBUILD, and I got a working program.

Anonymous comment on 2012-09-26 12:56

I can.

inflating: mupdf-6e7b3ab/thirdparty/freetype-2.4.10/docs/GPLv2.TXT
inflating: mupdf-6e7b3ab/thirdparty/freetype-2.4.10/docs/raster.txt
inflating: mupdf-6e7b3ab/thirdparty/freetype-2.4.10/docs/formats.txt
inflating: mupdf-6e7b3ab/thirdparty/freetype-2.4.10/
inflating: mupdf-6e7b3ab/thirdparty/freetype-2.4.10/version.sed
cd src && make all LIBDIR="`ocamlc -where`"
make[1]: Entering directory `/tmp/makepkg/src/repo/3rdp/lablGL-1.04/src'
ocamlc -pp camlp4o -o var2def
ocamlc -pp camlp4o -o var2switch
ocamlrun ../src/var2def < gl_tags.var > gl_tags.h
ocamlrun ../src/var2switch -table GL_ < gl_tags.var > gl_tags.c
Fatal error: cannot find file '../src/var2def'
make[1]: *** [gl_tags.h] Error 2
make[1]: *** Waiting for unfinished jobs....
Fatal error: cannot find file '../src/var2switch'
make[1]: *** [gl_tags.c] Error 2
make[1]: Leaving directory `/tmp/makepkg/src/repo/3rdp/lablGL-1.04/src'
make: *** [lib] Error 2
==> ERROR: A failure occurred in build().

/tmp/makepkg/src/repo/3rdp/lablGL-1.04/src/var2def exists.

mfwitten commented on 2012-09-25 16:09

Unfortunately, I cannot reproduce your bug.

bernarcher commented on 2012-09-25 03:33

llpp-git 20120924-1 does not build:

make[1]: Entering directory `/var/abs/local/yaourtbuild/llpp-git/src/repo/3rdp/lablGL-1.04/src'
ocamlc -pp camlp4o -o var2def
ocamlc -pp camlp4o -o var2switch
ocamlrun ../src/var2def < gl_tags.var > gl_tags.h
Fatal error: cannot find file '../src/var2def'

The file exists properly, however:
bp:~$ ls -l var2def
-rwxr-xr-x 1 bp users 90K 25. Sep 05:15 /var/abs/local/yaourtbuild/llpp-git/src/repo/3rdp/lablGL-1.04/src/var2def

mfwitten commented on 2012-09-10 01:22

I also just got it installed with no problems, using revision 1690a17951096084b32be6870801c8d9ce1b18de

karol_007 commented on 2012-09-10 00:41

I've just installed it w/o a problem.

blackout24 commented on 2012-09-10 00:34

Even after fixing the download path and freetype version manually it doesn't compile.
yaourt-tmp-root/aur-llpp/src/llpp/3rdp/mupdf-af5a608/thirdparty/freetype-2.4.10/include/ft2build.h:34:38: critical error: freetype/config/ftheader.h: File not found.

Which doesn't make any sense because the file is clearly there.

mfwitten commented on 2012-08-20 01:32

I sent a patch to the maintainer upstream; the easiest solution is simply to change the following line in `':




That is, add the `archive/' path component. This fixes the freetype version mismatch as well, because all of these third party components are hard coded with each other.

mfwitten commented on 2012-08-20 00:54

The problem is upstream; this PKGBUILD is not out-of-date.

Anonymous comment on 2012-08-19 16:45

Also the freetype version is now 2.4.10 (to change in

Torsten commented on 2012-08-17 14:08

"" is not upto date, the current link should be:

or better:

mfwitten commented on 2012-07-04 22:22

An `llpp.desktop' file has been added, and `mesa' has been listed as a dependency (nothing seems to depend on `glut', namely `freeglut'). Thanks for the input!

Anonymous comment on 2012-07-04 19:55

This pacakge also requires a GL library, i.e. freeglut, to build and run.

pfrenssen commented on 2012-07-03 14:21

Could you install a llpp.desktop file in /usr/share/applications/? This comes in handy for setting llpp as the default application for PDF files. I have posted the .desktop file I'm using at

mfwitten commented on 2012-04-20 14:35

Thanks. I added `unzip' to the makedepends array

Anonymous comment on 2012-04-20 09:11

The build fails without the tool unzip (used to extract 3rd party dependencies during "Compile"). Otherwise, seems to works fine. Revision: 3152db87e9ad836b3416df51d9fc36888b215444

mfwitten commented on 2012-03-19 19:23

This revision worked for me just now (it builds, installs, and runs): 113e537ef9a1b14fc29911b971214b4e08bda0a7

silenc3r commented on 2012-03-14 20:17

It doesn't work in openbox either. I can't even build it now.

silenc3r commented on 2012-03-14 20:16

It doesn't work in openbox either. I can't even build it at the moment.

silenc3r commented on 2012-03-14 11:36

Cleaning 3rd party dependencies didn't help. I'm still getting the same error:
Fatal error: exception Failure("X connection failed maj=11 min=0 reason="No protocol specified\n"")
It doesn't matter if I try to open pdf file or mp3, error is the same. I think that problem may be caused by my window manager - xmonad, but I'll have to install openbox or something to verify that.

mfwitten commented on 2012-03-05 04:44

I just tested the latest revision (0971dd948ff446ab76aa863f84aeb004a3d2f903) with success.

mfwitten commented on 2012-03-05 04:42

If there are problems building or running llpp, then I suggest manually refreshing the third party dependencies. Currently, you can achieve this by setting the following in your PKGBUILD:


Note that the `_clean_keep_3rd_party_deps' variable is being set to the empty string (the null string).

silenc3r commented on 2012-03-04 17:34

llpp compies fine, but I get this error when I'm trying to open file:
Fatal error: exception Failure("X connection failed maj=11 min=0 reason="No protocol specified\n"")

aksr commented on 2012-02-23 18:28

I get this, when I start llpp: Fatal error: exception Failure("X connection failed maj=11 min=0 reason="No protocol specified\n"")

xmw commented on 2012-01-28 22:31

Given memento.h from mupdf-git is installed in /usr/include

sed -e s/pdf_xref/pdf_document/ \
-e s/pdf_open_xref/pdf_open_document/ \
-e s/pdf_free_xref/pdf_close_document/ \
-i link.c || die

chneukirchen commented on 2012-01-23 15:26

Anyone know how to fix this?

./link.c:384:5: error: too many arguments to function ‘pdf_open_xref’
./link.c:627:5: error: too many arguments to function ‘fz_new_draw_device’
./link.c:628:5: error: too few arguments to function ‘pdf_run_page’
./link.c:765:25: error: ‘fz_outline’ has no member named ‘page’
./link.c:862:9: error: too few arguments to function ‘pdf_run_page’
./link.c:1206:5: error: unknown type name ‘pdf_link’
./link.c:1217:57: error: request for member ‘next’ in something not a structure or union
./link.c:1221:20: error: request for member ‘rect’ in something not a structure or union

chneukirchen commented on 2012-01-03 15:25 seems to have issues, use _gitroot= for now.

Barthalion commented on 2011-11-30 19:49

Could someone package installed llpp with bacman (community/pacman-contrib) for x86-64?

mfwitten commented on 2011-11-22 05:19

It would appear that it is not the package itself that is out of date, but rather one of the dependencies that is automatically built (lablGL). You could manually download an older version of the lablGL source into the appropriate directory until upstream gets it sorted out. That's the nature of developmental builds!

mutterschiff commented on 2011-08-22 12:34

no problems here, works like a charm - try again?

johnnyponny commented on 2011-08-06 18:32

I get this error when installing

''cvs [checkout aborted]: connect to failed: Connection timed out''

kazuo commented on 2011-08-03 10:31


We need to build the deps inside the PKGBUILD? Any reason to it?

I'm using a modified PKGBUILD with external deps (with mupdf-git as mupdf provider, we need the git version?), if one need svn/cvs/git of the deps he can build it and use a provider.


mfwitten commented on 2011-07-08 18:42

1) You should have had the `db' package already; to build `llpp-git', you neend subversion, which depends on `apr-util', which depends on `db'. For some reason, your system was inconsistent.

2) If `pacman' worked, then that's all that matters :-P Please do file a report with the `packer' maintainers.

tbhartman commented on 2011-07-08 14:55

I had a few issues building...

1) First time it looked for and couldn't find ''. I installed extra/db and it proceeded to build correctly. Is this a dependency?
2) (btw, I use packer)...After building correctly, it prompted "Proceed with installation? [Y/n]", to which I entered nothing and hit ENTER (usually works) and it did nothing. Had to manually go to the built package and install with 'pacman -U'. This is probably a packer issue though.


mfwitten commented on 2011-06-11 02:26

I added `xsel' in the `depends' array.

flienteen commented on 2011-06-10 16:45

i think ”xsel” should be added to the list of dependencies..

darkvenger commented on 2011-04-20 15:48

I also understand (and share) your reluctance into using something like this, but it also seems to me the least evasive solution.

Keep up the good work.

mfwitten commented on 2011-04-20 14:44

That's indeed a good idea; I wasn't sure whether or not I wanted to put something like:


somewhere, but I decided that limiting the side effect conveys the intention best:


Unfortunately, the += doesn't seem to work there (currently).


darkvenger commented on 2011-04-20 08:05

Hello again mfwitten, you made think on that "heavy ignore" issue :).
I believe that make doesn't have that many options (besides -j) that could be defined globally to be used in all builds, but because each one of us is a unique being ;).
I did a little testing and, it seems that, to only overwrite the -j option while maintaining the user's MAKEFLAGS you could add MAKEFLAGS=$MAKEFLAGS" -j1" just before (for example) bash
Note that a whitespace is needed before -j1.

mfwitten commented on 2011-04-20 03:03

@darkvenger: Thanks! It seems a little heavy handed to ignore a user's `makeflags', but I've gone ahead and made the change you suggested.

darkvenger commented on 2011-04-19 23:04

Thought you should know.
I had a problem with my custom makeflags=-j3 configuration.
To avoid future problems, in other users, I suggest you to also add !makeflags to the options array.

bal commented on 2011-03-30 08:03

Change 'svn' to 'subversion' in makedepends.

archdria commented on 2011-01-30 01:56

I get this while compiling:

Sara commented on 2011-01-09 04:20

Sorry for not having thought to check my makepkg.conf; I had some make flags that caused the issue.

However, a new compile error has arisen due to an error in sumatrapdf (which llpp currently uses). It'll result in this terminal output when you attempt to compile:
pdf_font.c:(.text+0x1c1): undefined reference to `pdf_ft_free_vsubst'
collect2: ld returned 1 exit status
make: *** [build/release/pdfdraw] Error 1
/home/sara/abs/aur/llpp-git/src/llpp/3rdp/mupdf/build/release/libmupdf.a(pdf_build.o): In function `pdf_showtext':
pdf_build.c:(.text+0x2373): undefined reference to `pdf_ft_get_vgid'
/home/sara/abs/aur/llpp-git/src/llpp/3rdp/mupdf/build/release/libmupdf.a(pdf_font.o): In function `pdf_dropfont':
pdf_font.c:(.text+0x1c1): undefined reference to `pdf_ft_free_vsubst'
collect2: ld returned 1 exit status

I e-mailed the developer about this, and the solution is to edit the to use the mupdf git repo instead (he said that sumatrapdf is, in fact, no longer even needed).

I've posted my patch to the in the Arch pastebin:

To use, add before bash (in the PKGBUILD, presuming you've added the patch as a source):
patch -p0 -i "${srcdir}"/buildall.patch || return 1

I'm going to bet that the developer will fix the script himself sometime soon, but in the meanwhile, you can use my patch to be able to compile llpp.

mfwitten commented on 2010-12-25 15:06

I removed `src' and rebuilt with `makepkg -sfi' using `_source=yes' and `_clean=yes' and everything went well for me.

The `var2def' program is part of the `lablgl' dependency that llpp's build scripts download. The build log should show that it was created with the this command: `ocamlc -pp camlp4o -o var2def' and the binary that is produced should be located here: `repo/3rdp/lablgl/src/var2def' relative to "$srcdir".

Furthermore, the command `ocamlrun ../src/var2switch GLU_ < glu_tags.var > glu_tags.c' produces no warnings or errors of any kind on my system.

I'm sorry that I can't help you resolve the issue.

Sara commented on 2010-12-23 21:18

I tried your suggestion (keeping _source=yes and letting _clean=yes), but a clean rebuild didn't work.

I send the developer a copy of my compile log, and he was able to identify the exact error (occurs earlier in the compile than the error I posted):
ocamlrun ../src/var2switch GLU_ < glu_tags.var > glu_tags.c
Fatal error: cannot find file ../src/var2def

Again, I don't have a problem producing an llpp binary without the PKGBUILD (doing so in the manual way I described before), which is rather strange. Thanks for looking into this.

mfwitten commented on 2010-12-23 04:34

I was unable to reproduce this problem on my system; given that llpp's own build scripts handle depedencies on their own, my guess is that there is some mismatch between llpp's code and the Glut implementation that llpp's build scripts failed to update properly; IIRC, the build script doesn't actually do anything smart to figure out such situations.

I suggest setting `_clean=yes' in the PKGBUILD if it is not already set; this will remove the external dependencies that llpp's build script downloaded, forcing them to be downloaded again (hopefully to proper versions).

If there is a particular version of llpp to which you want to revert, then you can set `_source=' in the PKGBUILD and then checkout that version by hand in the git repo:

pushd src/repo
git checkout <commit-or-tag-or-whatever>
makepkg -sfi

I was able to build with `_source=yes' (the most recent commit from the official repo) just a few minutes ago; this was commit:


Sara commented on 2010-12-23 01:36

frabjous, your error has been fixed (I e-mailed the developer about it), but I'm having another error that only occurs when I use the PKGBUILD. Using the PKGBUILD, the compile aborts with:
File "./", line 437, characters 6-24:
Error: Unbound module Glut

But with simply doing:
$ git clone git://
$ cd llpp
$ sh

the build goes through perfectly, producing the llpp binary. Any idea what's up?

frabjous commented on 2010-12-08 16:32

I cannot build this.

Here's the tail of the yaourt output:

LD build/release/mupdf
link.o: In function `mainloop':
link.c:(.text+0x224a): undefined reference to `fz_clearpixmapwithcolor'
collect2: ld returned 1 exit status
File "_none_", line 1, characters 0-1:
Error: Error while building custom runtime system
==> ERROR: Makepkg was unable to build llpp-git.

Anonymous comment on 2010-11-13 21:27

Nice app, thanks! But imho your PKGBUILD is a big mess, you don't have to put these things in there! I don't say my version is perfect, but it's better