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: None
Last Packager: aksr
Votes: 62
Popularity: 0.63
First Submitted: 2010-10-26 22:21 (UTC)
Last Updated: 2020-03-18 06:05 (UTC)

Latest Comments

MarsSeed commented on 2022-05-03 09:59 (UTC) (edited on 2022-05-03 10:00 (UTC) by MarsSeed)

@alerque: Removed flag-out-of-date.

alerque commented on 2022-05-03 09:41 (UTC)

Package does need work, but flag reason is not really valid and the problem is upstream. Using the system mupdf is not an option since upstream decided to rely on unreleased changed (note this is holding up the [community] package too). The download should be moved to source=() but the fact that it needs to download the sources isn't wrong. Possibly the mupdf-git package could be used and the build system patched to use that.

MarsSeed commented on 2022-03-16 11:56 (UTC)

Clones git repo of mupdf inside build() function, even though it is installed.

==> Starting build()...
mupdf does not exist, fetching it from git://

Also it goes on to download all submodule repos.

Please kindly fix this issue.

alerque commented on 2020-03-03 08:19 (UTC)

Please update the optdepends for prince to just 'prince' (not 'princexml'), currently provided by the prince-bin package. The old package will be merged into that shortly and eventually the provides for the old name will go away.

frabjous commented on 2019-01-23 15:36 (UTC)

Thanks a lot acgtyrant. Not sure why aksr isn't either fixing things or disowning the package.

acgtyrant commented on 2018-08-16 21:50 (UTC)

A temporary worked PKGBUILD:

However it missing llpp.desktop and so on, see

mindbound commented on 2018-06-24 12:37 (UTC)

I'm getting the same error as @dreieck.

dreieck commented on 2018-06-07 09:28 (UTC)

Fails to build for me with

==> Starting build()...
muPDF not found, consult ./BUILDING
fail 0 sec
==> ERROR: A failure occurred in build().

I have the packages mupdf and libmupdf installed.

Also, symlinking /usr/bin/mupdf to /usr/bin/muPDF does not help out.

aksr commented on 2018-04-17 07:42 (UTC)

hero: Updated. (Btw, man-pages are not /really/ man-pages).

hero commented on 2018-04-10 07:18 (UTC)

The script has changed a little, here is a diff that builds the package again for me: (Remove the trailing '/diff' for plain text)

I also included the new man pages and I removed the install file, because a pacman hook exists for that (See /usr/share/libalpm/hooks/update-desktop-database.hook)

hero commented on 2017-12-14 07:44 (UTC)

Because llpp does not use the versioned mupdf library it most of the time does not compile, because it uses features that are added only in the git mupdf version. Now mupdf has been updated recently and it is now the beginning of a period of time, where llpp-git compiles against the mupdf library shipped in Arch. So I suggest to update the pgkver, in order to cause an update with the AUR helpers now that it is possible again to compile llpp on Arch with the shipped libraries. The PKGBUILD seems to still work, so there should nothing else need to be done other than to update the pkgver. The pkgver I got after just updating llpp-git was the following "26b.r58.gc654792".

kngwyu commented on 2017-11-02 14:36 (UTC)

@respiranto Original source looks like modified with this commit in mupdf,;a=commitdiff;h=626ea2ea771735492c9a4350ae02b26ea09d1423, but Arch's mupdf is still version 1.11 released in April this year. I think this is the cause of the compile error.

respiranto commented on 2017-10-29 20:12 (UTC)

Fails to build again [0]. [0]

hero commented on 2017-04-11 21:16 (UTC)

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. Cheers

menta commented on 2016-12-15 18:14 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC) (edited on 2016-01-10 07:23 (UTC) by tutu)

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+' to 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 (UTC)

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

tutu commented on 2016-01-04 07:34 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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'... done. ==> 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} \ /tmp-yaourt/yaourt-tmp-ruben/aur-llpp-git/pkg/llpp-git/usr/share/bash-completion/completions 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(). Aborting... ==> ERROR: Makepkg was unable to build llpp-git.

CjK commented on 2015-01-25 22:29 (UTC)

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

windowsrefund commented on 2015-01-08 22:32 (UTC)

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 (UTC)

Should work now.

holos commented on 2014-09-03 17:52 (UTC)

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 (UTC)

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

stevenhoneyman commented on 2014-08-17 16:06 (UTC)

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

alxarch commented on 2013-12-25 09:52 (UTC)

Latest build on fresh installation requires glu also

darkxsun commented on 2013-10-16 15:26 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

Updated PKGBUILD for pacman 4.1 ==>

commented on 2013-02-01 12:53 (UTC)

PKGBUILD still needs MAKEFLAGS='-j1'

mutterschiff commented on 2012-10-02 06:27 (UTC)

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 (UTC)

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 fi }

zaza commented on 2012-09-28 12:24 (UTC)

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

bernarcher commented on 2012-09-27 21:12 (UTC)

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 (UTC)

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 (UTC)

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.

commented on 2012-09-26 12:56 (UTC)

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(). Aborting... /tmp/makepkg/src/repo/3rdp/lablGL-1.04/src/var2def exists.

mfwitten commented on 2012-09-25 16:09 (UTC)

Unfortunately, I cannot reproduce your bug.

bernarcher commented on 2012-09-25 03:33 (UTC)

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 (UTC)

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

karol_007 commented on 2012-09-10 00:41 (UTC)

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

blackout24 commented on 2012-09-10 00:34 (UTC)

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 (UTC)

I sent a patch to the maintainer upstream; the easiest solution is simply to change the following line in `': mupdf3p= to: mupdf3p= 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 (UTC)

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

commented on 2012-08-19 16:45 (UTC)

Also the freetype version is now 2.4.10 (to change in

Torsten commented on 2012-08-17 14:08 (UTC)

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

mfwitten commented on 2012-07-04 22:22 (UTC)

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!

commented on 2012-07-04 19:55 (UTC)

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

pfrenssen commented on 2012-07-03 14:21 (UTC)

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 (UTC)

Thanks. I added `unzip' to the makedepends array

commented on 2012-04-20 09:11 (UTC)

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 (UTC)

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

silenc3r commented on 2012-03-14 20:17 (UTC)

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

silenc3r commented on 2012-03-14 11:36 (UTC)

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 (UTC)

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

mfwitten commented on 2012-03-05 04:42 (UTC)

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: clean=yes _clean_keep_3rd_party_deps= 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 (UTC)

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"")

xmw commented on 2012-01-28 22:31 (UTC)

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 (UTC)

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 (UTC) seems to have issues, use _gitroot= for now.

Barthalion commented on 2011-11-30 19:49 (UTC)

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

mfwitten commented on 2011-11-22 05:19 (UTC)

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 (UTC)

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

commented on 2011-08-06 18:32 (UTC)

I get this error when installing ''cvs [checkout aborted]: connect to failed: Connection timed out''

kazuo commented on 2011-08-03 10:31 (UTC)

Hi, 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. My PKGBUILD:

mfwitten commented on 2011-07-08 18:42 (UTC)

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 (UTC)

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. Thanks!

mfwitten commented on 2011-06-11 02:26 (UTC)

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

flienteen commented on 2011-06-10 16:45 (UTC)

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

darkvenger commented on 2011-04-20 15:48 (UTC)

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 (UTC)

That's indeed a good idea; I wasn't sure whether or not I wanted to put something like: MAKEFLAGS+=' -j1' somewhere, but I decided that limiting the side effect conveys the intention best: MAKEFLAGS=$MAKEFLAGS' -j1' bash Unfortunately, the += doesn't seem to work there (currently). Thanks!

darkvenger commented on 2011-04-20 08:05 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

Change 'svn' to 'subversion' in makedepends.

swiftscythe commented on 2011-01-30 01:56 (UTC)

I get this while compiling:

Sara commented on 2011-01-09 04:20 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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> popd 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: b3870019678b7268a641b7561ef4bed61606d747

Sara commented on 2010-12-23 01:36 (UTC)

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 (UTC)

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 Aborting... ==> ERROR: Makepkg was unable to build llpp-git.

commented on 2010-11-13 21:27 (UTC)

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