Package Details: llpp-git 30.r22.g6905dbc-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: 60
Popularity: 0.000261
First Submitted: 2010-10-26 22:21
Last Updated: 2019-02-03 08:48

Dependencies (37)

Required by (0)

Sources (1)

Latest Comments

« First ‹ Previous ... 4 5 6 7 8 9 10 Next › Last »

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.

swiftscythe 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: