Arch Linux User Repository

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

In my case I was able to build again after the downgrade, but that was a different error from yours. Are you using any build chain components or dependencies that are non-standard variants (AUR, testing)?

unfortunately build aborts even with binutils downgraded to 2.34

@kinoe: I can't reproduce your exact error but building with the latest binutils fails for me with a different (but similar) message.

My guess is a bug in binutils, likely: https://bugs.archlinux.org/task/67671 As a workaround you can try downgrading binutils to v2.34

build stopped

[485/485] SOLINK ./libpdfium.so
FAILED: libpdfium.so libpdfium.so.TOC 
/usr/bin/python2 "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="nm" --sofile="./libpdfium.so" --tocfile="./libpdfium.so.TOC" --output="./libpdfium.so" -- g++ -shared -Wl,-soname="libpdfium.so" -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed -fuse-ld=gold -Wl,--threads -Wl,--thread-count=4 -m64 -Wl,-O2 -Wl,--gc-sections -rdynamic -Wl,-rpath=\$ORIGIN -o "./libpdfium.so" @"./libpdfium.so.rsp"
malloc(): smallbin double linked list corrupted
collect2: fatal error: ld terminated with signal 6 [Aborted], core dumped
compilation terminated.
ninja: build stopped: subcommand failed.

@WonderCaT_007: Thanks for reporting. I don't think you need to be concerned. The files in question are part of Pdfium's test corpus and they probably are present to test if Pdfium is vulnerable to the exploits contained.

None of these files are being installed or run by the package and as the package comes with javascript support disabled many exploits won't work anyway.

While I still wouldn't recommend opening these with a pdf reader I don't think they contain malicious code (probably the exploit only, no payload). But that is just my assumption, upstream can probably tell you more.

The package was creation was successful. However, I did a clamav scan of the build directory and it detected two files as malicious or contains some kind of exploit code. To confirm the detection, I just checked those files with online virustotal, and one of them were detected by 18 anti virus engines. Should we be concerned?

Here are the files: libpdfium-nojs/src/pdfium/testing/resources/js.pdf: Pdf.Dropper.Agent-7158272-0 FOUND < Detected by 18 av engines in Virustotal

libpdfium-nojs/src/pdfium/testing/resources/pixel/bug_867501.pdf: Pdf.Exploit.TALOS_2018_0639-6680787-0 FOUND < Detected just by clamav

Yes, installing pkgconf solved the problem for me.

@paarthi: Works for me. Pkgconfig is probably missing or defect on your system, so you should check if it is present and working correctly.

This package is not building on my computer.

ERROR at //build/config/linux/pkg_config.gni:103:17: Script returned non-zero exit code.
    pkgresult = exec_script(pkg_config_script, args, "value")
                ^----------
Current dir: /home/paarth/.cache/yay/libpdfium-nojs/src/pdfium/out/Release/
Command: /usr/bin/python2 /home/paarth/.cache/yay/libpdfium-nojs/src/pdfium/build/config/linux/pkg-config.py gio-2.0
Returned 1.
stderr:

Could not run pkg-config.

See //build/linux/BUILD.gn:10:3: whence it was called.
  pkg_config("gio_config") {
  ^-------------------------
See //build/config/freetype/BUILD.gn:10:24: which caused the file to be included.
    public_configs = [ "//build/linux:freetype_from_pkgconfig" ]
                       ^--------------------------------------
==> ERROR: A failure occurred in build().
    Aborting...
Error making: libpdfium-nojs

Hi PedroHLC,

I am well aware that this package is some kind of chimera between a VCS and a stable package. If I could simply use fragment to clamp to a specific release tag I would already have done so or I wouldn't use git to get the source at all.

The problem here is that upstream does not use tags at all. Pdfium releases as defined by Chromium are branches and these branches are moving targets as they occasionly do get security and other fixes backported.

With upstream being a moving target I opted for the current mechanism to create a package version that is able to keep track of the backported fixes (this is only possible by comparing the master and stable branch) and delivering the current stable version.

I'm open to discussion for clamping this package to a known stable branch instead of dynamically checking which branch is the latest stable, but I can't do proper release management without keeping track of the backport commits.

I'm also open to resubmitting the current version of this package as something like libpdfium-nojs-stable-git.