Package Details: libpdfium-nojs 6778.r0.7a8409531f-1

Git Clone URL: https://aur.archlinux.org/libpdfium-nojs.git (read-only, click to copy)
Package Base: libpdfium-nojs
Description: Open-source PDF rendering engine.
Upstream URL: https://pdfium.googlesource.com/pdfium/
Keywords: pdf pdfium
Licenses: BSD
Conflicts: libpdfium-bin
Provides: libpdfium
Submitter: selmf
Maintainer: selmf
Last Packager: selmf
Votes: 23
Popularity: 0.87
First Submitted: 2017-07-30 18:14 (UTC)
Last Updated: 2024-11-19 08:21 (UTC)

Pinned Comments

selmf commented on 2021-05-24 11:20 (UTC)

Important: This package depends on libicuuc and needs to be rebuild if the icu package is updated on your system!

Latest Comments

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

dangpzanco commented on 2022-01-05 23:35 (UTC) (edited on 2022-01-05 23:36 (UTC) by dangpzanco)

@selmf @chmouel I think the error is not fixed yet. I did a clean build and:

> pamac clean -b
> pamac install libpdfium-nojs
==> Starting build()...
ERROR at //build/config/dcheck_always_on.gni:8:1: Unable to load "/var/tmp/pamac-build-daniel/libpdfium-nojs/src/pdfium/build/config/gclient_args.gni".
import("//build/config/gclient_args.gni")
^---------------------------------------
See //build/config/BUILD.gn:9:1: whence it was imported.
import("//build/config/dcheck_always_on.gni")
^-------------------------------------------
See //build/config/BUILDCONFIG.gn:317:3: which caused the file to be included.
  "//build/config:feature_flags",
  ^-----------------------------
==> ERROR: A failure occurred in build().
    Aborting...

selmf commented on 2022-01-05 21:33 (UTC)

@chmouel: Sorry, I was a little too eager and removed one fix too many. It should work again now.

@FabioLolix: That is a reasonable request and I will look into it.

chmouel commented on 2022-01-05 20:07 (UTC)

getting an error building the last update :

ERROR at //build/config/dcheck_always_on.gni:8:1: Unable to load "/home/chmouel/.cache/yay/libpdfium-nojs/src/pdfium/build/config/gclient_args.gni". import("//build/config/gclient_args.gni") ^--------------------------------------- See //build/config/BUILD.gn:9:1: whence it was imported. import("//build/config/dcheck_always_on.gni") ^------------------------------------------- See //build/config/BUILDCONFIG.gn:317:3: which caused the file to be included. "//build/config:feature_flags", ^----------------------------- ==> ERROR: A failure occurred in build(). Aborting... checking dependencies... :: vim optionally requires python2: Python 2 language support

FabioLolix commented on 2021-12-09 17:51 (UTC)

Hello, this pkgbuild need conflicts libpdfium instead of libpdfium-bin, and IMO could be re-uploaded simply as libpdfium (who need js could upload libpdfium-js)

selmf commented on 2021-11-17 10:56 (UTC)

With the latest Chromium update, this package is broken again. This time it is a little bit more severe than usual due to some bugs in the build system and the addition of a new dependency, the abseil-cpp library. Abseil is available as an Arch Linux package, so I would very much like to make use of it, but it is a bit complicated to make this work.

selmf commented on 2021-10-14 13:33 (UTC)

@kirija: There is no need to install a different version of ICU. The system installation of ICU is integrated via a process called unbundling, which involves creating shim headers using a script that is downloaded during the prepare step. The log you posted indicates that something went wrong there and the shim was not created. As the build still works for me and I haven't had the time to test this in a clean environment I'd suggest you simply give it another go. If it keeps failing, I will take a closer look.

kirija commented on 2021-10-13 02:34 (UTC) (edited on 2021-10-13 02:38 (UTC) by kirija)

I got this build time error

  In file included from ../../core/fpdfapi/parser/cpdf_data_avail.cpp:28:
  ../../core/fxcrt/fx_extension.h:18:10: fatal error: third_party/icu/source/common/unicode/uchar.h: No such file or directory
     18 | #include "third_party/icu/source/common/unicode/uchar.h"
        |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  compilation terminated.
  [48/461] CXX obj/third_party/pdfium_base/partition_alloc.o
  [49/461] CXX obj/core/fdrm/fdrm/fx_crypt.o
  [50/461] CXX obj/third_party/pdfium_base/page_allocator.o
  [51/461] CXX obj/core/fdrm/fdrm/fx_crypt_aes.o
  [52/461] CXX obj/core/fpdfapi/parser/parser/cpdf_crypto_handler.o
  [53/461] CXX obj/core/fpdfapi/parser/parser/cpdf_cross_ref_table.o
  [54/461] CXX obj/core/fdrm/fdrm/fx_crypt_sha.o
  [55/461] CXX obj/core/fpdfapi/parser/parser/cpdf_dictionary.o
  [56/461] CXX obj/core/fpdfapi/parser/parser/cpdf_document.o
  ninja: build stopped: subcommand failed.
  ==> ERROR: A failure occurred in build().

At the time of this install there is actually icu already installed, lib32-icu and icu. So it looks like the error lies in the icu version I am using. Therefore I am installing icu-git but installation breaks because it obviously conflicts with the icu already installed and the existing icu is a dependency of some other programs. What's the solution?

selmf commented on 2021-09-20 08:04 (UTC)

@yar: Thanks for notifying me of this problem, It probably would have taken me some time to discover it on my own - the master branch still works for me and it looks like upstream's setup is made in a way that main is the new default but old clones using master will keep working. I'm currently investigating a good way to make the package agnostic to the name of the default branch, so this works both for new users and for those having older source checkouts.

yar commented on 2021-09-17 12:04 (UTC) (edited on 2021-09-17 12:04 (UTC) by yar)

I got these errors. Replacing "master.." with "main.." fixed it. I guess upstream changed their default branch name?

==> Starting pkgver()...
==> ERROR: pkgver is not allowed to contain colons, forward slashes, hyphens or whitespace.
==> ERROR: pkgver() generated an invalid version: fatal: ambiguous argument 'master..': unknown revision or path not in the working tree.

selmf commented on 2021-09-10 17:27 (UTC)

Sorry for taking a while, but the fix is up and running now.

@evgen23, @jeyes: Thanks for taking the time to help out while I was busy. I would have taken evgen23's patch, but I managed to locate the upstream fix and using this via cherry-pick is both easier and upstream tested, so I did.

Let me know if this still gives you troubles ...