Arch Linux User Repository

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

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.

Hi selmf.

Please, follow the ArchWiki VCS's guideline https://wiki.archlinux.org/index.php/VCS_package_guidelines, resubmitting. this package as libpdfium-nojs-git.

And in this one use chromium stable releases tags and use fragment (https://jlk.fjfi.cvut.cz/arch/manpages/man/PKGBUILD.5#USING_VCS_SOURCES) to lock specifically to that tag.

This way is clearer for the end user what kind of package he installed, it's easy to keep dependencies synced, and AUR helpers understand they need to check pkgver() to find updates...

PKGBUILD need a update of pkgver to 4044.r0.04bb1f2f03-1 ?

@steinbuch: Not sure what your issue is, I just tested it and the build ran fine on my system.

Using depot_tools is something I intentionally avoid doing for this package. It pulls lots of unneeded source dependencies and my goal is to unbundle all third party stuff and slim down the build as much as possible.

As this is a semi-git-package that tracks Chromium's stable branch to decide which checkout of the pdfium code to use breakage can happen when Chromium releases a new version. If this occurs you can just send me an out of date notification ;)