Hello and first of all thank you for providing the binaries.

I see that build.sh mentions MINGW*. Does this mean that the build is supposed to work on MSYS2+Mingw-w64 ?

built with V8 enabled but when testing with:

#include "fpdf_libs.h"

int main()
{
// Determine the path to files in the res folder from the archive
const char* resPath = "D:\pdfium-binaries\staging\res\";

// Initialize V8 and other embedded libraries
FPDF_InitEmbeddedLibraries(resPath);

// Make use of PDFium
FPDF_InitLibrary();
FPDF_DestroyLibrary();

}

v8.cc line #178 throws error:
CHECK(!FLAG_interpreted_frames_native_stack || !FLAG_jitless)

Do you know how to change build to fix this issue?

Just so you know :) happy to help build the linux binaries

Is the license info complete? There is a third_party directory which holds components with different licenses that might be included during build.

Thank you very much for this project hosting pre-built binaries, that helps a lot to experiment with the library before spending time to properly setup all tools to make self builds.
I see something odd with 3317, there are only archives for Windows, but those are nearly empty (no actual binary in it). Just as if they were the result of an automated build / deploy which failed building.
I'm happily and successfully using the builds from October for now.

Are the binaries in this repository supposed to work on AWS Lambda?

I'm trying to build libvips with pdfium support using lambci/lambda:build-go1.x Docker image, but it fails:

make[3]: Entering directory `/build/vips-8.9.2/libvips'
/bin/sh ../libtool  --tag=CXX   --mode=link g++  -g -O2 -no-undefined -version-info 54:2:12   -o libvips.la -rpath /opt/lib  resample/libresample.la arithmetic/libarithmetic.la colour/libcolour.la conversion/libconversion.la convolution/libconvolution.la deprecated/libdeprecated.la foreign/libforeign.la freqfilt/libfreqfilt.la histogram/libhistogram.la draw/libdraw.la iofuncs/libiofuncs.la morphology/libmorphology.la mosaicing/libmosaicing.la create/libcreate.la -lz     -lpng12    -ltiff   -ljpeg   -pthread -lgthread-2.0 -lglib-2.0   -Wl,--export-dynamic -pthread -lgmodule-2.0 -lgobject-2.0 -lglib-2.0   -L/opt/lib -lexpat     -llcms2      -L/opt/lib -lpdfium -lc++ -licuuc         -lm 
libtool: link: g++  -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-amazon-linux/4.8.5/../../../../lib64/crti.o /usr/lib/gcc/x86_64-amazon-linux/4.8.5/crtbeginS.o  -Wl,--whole-archive resample/.libs/libresample.a arithmetic/.libs/libarithmetic.a colour/.libs/libcolour.a conversion/.libs/libconversion.a convolution/.libs/libconvolution.a deprecated/.libs/libdeprecated.a foreign/.libs/libforeign.a freqfilt/.libs/libfreqfilt.a histogram/.libs/libhistogram.a draw/.libs/libdraw.a iofuncs/.libs/libiofuncs.a morphology/.libs/libmorphology.a mosaicing/.libs/libmosaicing.a create/.libs/libcreate.a -Wl,--no-whole-archive  -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -lz -lpng12 -ltiff -ljpeg -lgthread-2.0 -lgmodule-2.0 -lgobject-2.0 -lglib-2.0 -L/opt/lib /usr/lib64/libexpat.so -llcms2 -lpdfium -lc++ -licuuc -L/usr/lib/gcc/x86_64-amazon-linux/4.8.5 -L/usr/lib/gcc/x86_64-amazon-linux/4.8.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-amazon-linux/4.8.5/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-amazon-linux/4.8.5/crtendS.o /usr/lib/gcc/x86_64-amazon-linux/4.8.5/../../../../lib64/crtn.o  -g -O2 -pthread -Wl,--export-dynamic -pthread   -pthread -Wl,-soname -Wl,libvips.so.42 -o .libs/libvips.so.42.12.2
/usr/bin/ld: cannot find -lc++
collect2: error: ld returned 1 exit status

Thanks for any help or pointers.

It seems PDFium is built without #defining PDFIUM_PRINT_TEXT_WITH_GDI, therefore FPDF_SetPrintTextWithGDI function is missing.

Can this be added for Windows dlls?

Hello:
I am trying to upgrade my app with updating the library https://pub.dev/packages/native_pdf_view/versions 4.2 to 5.0 on Windows but it cant finish because is trying to get the file:
https://github.com/bblanchon/pdfium-binaries/releases/download/chromium/4638/pdfium-windows-x64.zip

Could you place again the file so everyone can use?
Regards.

Hi,

I have a similar project like yours (https://github.com/paulo-coutinho/pdfium-lib) and in my case it never generate the "libpdfium.a". Do you know why?

I need join all .o files manually and generate "libpdfium.a" manually.

Can you help me?

Thanks.

Hello,

I'm currently trying to make my repository, pypdfium2, compliant with the reuse standard. As I also need to build PDFium, I have incorporated most of the patches from this repository. May I ask under which license you would provide them? In general, could you please add a license file for the whole repository?

(This question also addresses @BoLaMN as I have the gclient_scm patch, too)

Many thanks!

Trying to call native method using .NET Core app from MAC application got crashed

For example i have called the following code but it will crashed

[DllImport("libpdfium.dylib", CharSet = CharSet.Ansi,CallingConvention =CallingConvention.Cdecl)]
    public static extern IntPtr FPDF_LoadCustomDocument([MarshalAs(UnmanagedType.LPStruct)]FPDF_FILEACCESS access, string password);

I am trying to build it for android but could not figure it out . Please share some process to build pdfium for android for which can be used like this library :-
https://github.com/barteksc/PdfiumAndroid

It would be desirable to be able to build binaries manually to integrate with build systems, and have full control over the output. Could you add the build script used to produce these binaries?

I found hints for skia support in the pdfium header files.

https://pdfium.googlesource.com/pdfium/+/refs/heads/master/public/fpdfview.h#878

Would it be possible to do an additional build for skia like for v8?

This project is really my only source for pdfium binaries.

Hi!

I have sucessfully built a Linux Arm 32-bit target within x86 Ubuntu and run on a raspbian based raspberry pi (within the manga reader app Kavita) by using the pdfium-binaries build files and setting CPU to arm (and downloading the Arm image). I was wondering if it would be a good idea to submit a pull request that adds such a target?

If so the way to do it I guess would be to modify the .travis.yml file and add a new matrix element (linux, TARGET_CPU=arm) as well as the appveyor.yml file by adding a new 'arm' platform?

The use case is as written above, adding pdf functionality to Kavita on raspberry pi.

Any thoughts? Thank you

Br/ Christoffer

I started getting pdfium error while trying to build my flutter project on windows. After doing some research I noticed that the latest version download URL in the file path in : [windows\flutter\ephemeral.plugin_symlinks\printing\windows\CMakeLists.txt] is not working.
It sounds like your gitup repo has a problem with the latest version download URLs for windows.
Can you check ?

Hi,

Awesome work !
Is it possible to add version on dlls cause it is 0.0.0.0 for now

Thanks

Hi,

Recently we added a 32-bit arm target to pdfium-binaries, this target has been working well in Kavita (self-hosted comic/book reader) since then, however, some of our users are running a 64-bit operating system on their raspberry pi and it looks like they are unable to use the 32-bit build.

I know there are issues with Travis credits but I wanted to ask how feasible it would be to add a 64-bit target. If it sounds ok I can see about submitting a pull request.

Thank you

Hi,

When I used the binaries from the version chromium/3671, I am getting access violation issue when the FPDF_LoadPage() method is accessed frequently. The images exported from the binaries are appearing as blank images. But when I used the binaries from the version chromium/3664, I am not facing the access violation exception and the blank image issue. I used windows-x64 assembly. Can you please check this?

Thanks,
Sabari

@bblanchon
I have created UWP viewer and tried add the pdfium.dll which built for windows x64 into my viewer using LaodPackagedLibrary method. But it returns a null IntPtr. LoadLibrary method also returned a null IntPtr.
Path.Exist(pathOfDLL) returns true.
My guess was dll was not compatible with UWP app.
I want to know whether I’m right?
Cause if so, I’m going to start building uwp compatible Pdfium dll.
Just need clarification and advice at the beginning.

Hi,

I've just attempted to test my PDFium Python bindings with the 32-bit Windows binary on an old Windows Vista device and ran into issues (crashing Python interpreter on FPDF_LoadDocument() call), which makes me assume Vista is just too old.
To confirm this guess, I'd like to ask: What is the minimum required Windows version for PDFium? What version of Windows is the binary built on? 10, probably?

Hello,

Thank you for your work. we can reduce so much time to spent our build by your work.
I found a lack of your code about cpp/fpdf_scopers.h which has the following code.

#include "public/cpp/fpdf_deleters.h"
#include "public/fpdf_annot.h"
#include "public/fpdf_dataavail.h"
#include "public/fpdf_edit.h"
#include "public/fpdf_formfill.h"
#include "public/fpdf_structtree.h"
#include "public/fpdf_text.h"
#include "public/fpdfview.h"

I expect you to fix like this.

#include "./fpdf_deleters.h"
#include "../pdf_annot.h"
#include "../fpdf_dataavail.h"
#include "../fpdf_edit.h"
#include "../fpdf_formfill.h"
#include "../fpdf_structtree.h"
#include "../fpdf_text.h"
#include "../fpdfview.h"

Cheers.

https://github.com/bblanchon/pdfium-binaries/releases/tag/chromium%2F4557
https://github.com/bblanchon/pdfium-binaries/releases/tag/chromium%2F4549

Helllo,
Are the binaries c or c++ dll's?
I'm asking because I use a compiler(fpc) that can't handle c++ dlls.

is that ok

Hi,

I made a iOS/MacOS repository that build it with success. Butt when execute my app with my static library for macOS it is freezing after open document:
https://travis-ci.com/prsolucoes/mobile-pdfium/jobs/279906862

My repository:
https://github.com/prsolucoes/mobile-pdfium

Do you know what can be wrong?

pdfinum-linux.tgz - the extension implies that the file is tarred and gzipped, but it's not.

$ file pdfium-linux.tgz
pdfium-linux.tgz: POSIX tar archive (GNU)
$ mv pdfium-linux.tgz pdfium-linux.tar
$ gzip pdfium-linux.tar
$ file pdfium-linux.tar.gz
pdfium-linux.tar.gz: gzip compressed data, was "pdfium-linux.tar", last modified: Sat Sep 18 16:42:14 2021, from Unix, original size modulo 2^32 5949440

there is no windows release in the last merge

i just build the library for android. but i got this:

i was build on ubuntu 18.04, and modified the linux args.gn like this:

is_component_build = false
pdf_enable_v8 = false
pdf_is_standalone = true
use_custom_libcxx=true
libcpp_is_static=true
target_cpu = "arm"
target_os = "android"

undefined reference errors:

It seems to me there may be a problem with the symbol names exported by the x86 DLL. Running a "dumpbin /exports" on x64 and x86 DLLs prints different exported names.

Here is 3 examples of exported symbol names by x64 DLL:
267 10A 0001A1FE FPDF_GetPageCount
275 112 00019CE8 FPDF_InitLibrary
278 115 00019D9F FPDF_LoadDocument

They become on x86 DLL:
267 10A 00016B70 _FPDF_GetPageCount@4
275 112 000166B8 _FPDF_InitLibrary@0
278 115 0001677C _FPDF_LoadDocument@8

Linux .so exported names are identical to x64 DLL ones. Is is possible to remove "_" prefix and "@*" suffix from x86 DLL exported names ?

i build pdfium-binaries on ubuntu 1804, i modified args/linux.args.gn by appending these two lines:

target_cpu="arm"
target_os="linux"

i set target_cpu="arm" , target_cpu="arm64" , target_cpu="x86", target_cpu="x64" to build the armeabi-v7a, arm64-v8a, x86, x86_64 shared library for android, both worked fine on my android app except only when set to arm not working.

i tried to set cFlags = [ "-march=armv7-a", "-mfpu=vfpv3-d16", "-mfloat-abi=hard"] in file pdfium/BUILD.gn, still not working with same error below:

Build command failed.
Error while executing process /Users/xiasenhai/Library/Android/sdk/cmake/3.6.4111459/bin/cmake with arguments {--build /Users/xiasenhai/Downloads/AndroidOfficeApplication/android-pdfium-library/.externalNativeBuild/cmake/debug/armeabi-v7a --target accelerometer}
[1/2] Building CXX object CMakeFiles/accelerometer.dir/sensorgraph.cpp.o
[2/2] Linking CXX shared library /Users/xiasenhai/Downloads/AndroidOfficeApplication/android-pdfium-library/build/intermediates/cmake/debug/obj/armeabi-v7a/libaccelerometer.so
FAILED: : && /Users/xiasenhai/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++ --target=armv7-none-linux-androideabi --gcc-toolchain=/Users/xiasenhai/Library/Android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64 --sysroot=/Users/xiasenhai/Library/Android/sdk/ndk-bundle/sysroot -fPIC -isystem /Users/xiasenhai/Library/Android/sdk/ndk-bundle/sysroot/usr/include/arm-linux-androideabi -D__ANDROID_API__=21 -g -DANDROID -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -mthumb -mfpu=neon -Wa,--noexecstack -Wformat -Werror=format-security -std=c++11 -fsigned-char -frtti -fexceptions -pthread -std=c++11 -std=c++11 -mthumb -Wall -Werror -O2 -mfpu=neon -mhard-float -D_NDK_MATH_NO_SOFTFP=1 -march=armv7-a -mfloat-abi=hard -O0 -fno-limit-debug-info -Wl,--fix-cortex-a8 -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libatomic.a -nostdlib++ --sysroot /Users/xiasenhai/Library/Android/sdk/ndk-bundle/platforms/android-21/arch-arm -Wl,--build-id -Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--fix-cortex-a8 -Wl,--exclude-libs,libunwind.a -L/Users/xiasenhai/Library/Android/sdk/ndk-bundle/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a -Wl,--no-undefined -Wl,-z,noexecstack -Qunused-arguments -Wl,-z,relro -Wl,-z,now -shared -Wl,-soname,libaccelerometer.so -o /Users/xiasenhai/Downloads/AndroidOfficeApplication/android-pdfium-library/build/intermediates/cmake/debug/obj/armeabi-v7a/libaccelerometer.so CMakeFiles/accelerometer.dir/sensorgraph.cpp.o /Users/xiasenhai/Downloads/AndroidOfficeApplication/android-pdfium-library/src/main/cpp/pdfium/lib/armeabi-v7a/libpdfium.so -landroid -lGLESv2 -llog -latomic -lm "/Users/xiasenhai/Library/Android/sdk/ndk-bundle/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a/libc++_static.a" "/Users/xiasenhai/Library/Android/sdk/ndk-bundle/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a/libc++abi.a" "/Users/xiasenhai/Library/Android/sdk/ndk-bundle/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a/libunwind.a" "-ldl" && :
/Users/xiasenhai/Library/Android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld: error: CMakeFiles/accelerometer.dir/sensorgraph.cpp.o uses VFP register arguments, output does not
/Users/xiasenhai/Library/Android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld: error: /Users/xiasenhai/Downloads/AndroidOfficeApplication/android-pdfium-library/src/main/cpp/pdfium/lib/armeabi-v7a/libpdfium.so uses VFP register arguments, output does not
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

i also tried these settings on my android app CMakeLists.txt

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O2 -mfpu=neon -mhard-float -D_NDK_MATH_NO_SOFTFP=1 -march=armv7-a -mfloat-abi=hard")

set( ANDROID_LINKER_FLAGS "" )

set( ANDROID_LINKER_FLAGS "-Wl,--fix-cortex-a8" )
set( CMAKE_SHARED_LINKER_FLAGS "${ANDROID_LINKER_FLAGS} ${CMAKE_SHARED_LINKER_FLAGS}" )
set( CMAKE_MODULE_LINKER_FLAGS "${ANDROID_LINKER_FLAGS} ${CMAKE_MODULE_LINKER_FLAGS}" )

steps/07-pack.sh

CFG=${CONFIGURATION:-Release}
V8=${V8:-disabled} 
OS=${PDFium_TARGET_OS:?}
CPU=${PDFium_TARGET_CPU:?}
VERSION=${PDFium_VERSION:-}
PATCHES="$PWD/patches"

STAGING="$PWD/staging"
SOURCE=${PDFium_SOURCE_DIR:-pdfium}
BUILD=${PDFium_BUILD_DIR:-pdfium/out}

the second line V8 value is not from build.sh
why not use V8=${PDFium_V8:-disabled}

there is PDFium_V8 config in the build.sh

#!/usr/bin/env bash
#
# Variables to provide:
# CONFIGURATION = Debug | Release
# PDFium_TARGET_CPU = x86 | x64 | arm | arm64
# PDFium_TARGET_OS = mac | linux | win
# PDFium_BRANCH = main | chromium/3211 | ...
# PDFium_V8 = enabled

I was wondering if there are any plans to have wasm builds as well?

Using dumpbin /headers with pdfium.dll indicates a 14.00 linker version which is VS 2015. So, is GYP_MSVS_VERSION=2017 really used? I also tried to set GYP_MSVS_OVERRIDE_PATH locally, but the result is the same. Perhaps something should change in vs_toolchain.py?

Firstly thanks for doing this project. I have a request to build pdfium without XFA support, as to reduce possible malicious attack vectors. I see for win x32 builds you already have disabled Javascript (pdf_enabled_v8 = false, great). Can you add the pdf_enable_xfa = false as well. Either in current build or separate build. Thank you.

Hi,
I have linking issue of pdium with libvips library and this is the trace that I have right now.

 CCLD     introspect
  CCLD     introspect

�[91m/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDF_GetPageHeight'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDF_LoadPage'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDF_CloseDocument'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDF_GetLastError'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDF_RenderPageBitmap'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDF_ClosePage'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDF_LoadMemDocument'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDF_InitLibraryWithConfig'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDFBitmap_CreateEx'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDF_GetMetaText'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDF_GetPageCount'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDF_GetPageWidth'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDFBitmap_Destroy'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ./.libs/libvips.so: undefined reference to `FPDF_LoadDocument'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:752: introspect] Error 1
make[3]: *** [Makefile:875: install-recursive] Error 1
make[2]: *** [Makefile:629: install-recursive] Error 1
make[1]: *** [Makefile:940: install-strip] Error 2
make: *** [Makefile:9: build] Error 2

I did raise the issue against libvips but could not get help there. Can you help me with this?

Note: I was able to succesfully link pdfium with libvips in alpine with this version - https://pdfium.googlesource.com/pdfium/+/4fcc1f28e25ec78d75e33264f1833336c37a3b3e
With upgrading to https://pdfium.googlesource.com/pdfium/+/bb85de36d277a449690e167f63a4ee988877f78d, I have this linking issue

Nice project.

Can you make for iOS?

Thanks.

When rastering this PDF on Linux using this library, all the text is missing. However, some other features like lines remain visible.
The same file works using the same code on Windows.

This has been reported here: DavBfr/dart_pdf#623
It can be reproduced with all the builds I tested.

The Linux code is here:
https://github.com/DavBfr/dart_pdf/blob/1ca69a1/printing/linux/print_job.cc#L248

The Windows code is here:
https://github.com/DavBfr/dart_pdf/blob/1ca69a1/printing/windows/print_job.cpp#L287

This file contains only embedded Type 1 fonts :

A file with embedded TTF fonts works:

I find it a bit confusing that the release for armv7l (e. g. Raspberry Pi 2) is named just linux-arm without any additional clarification. Maybe it would make sense to rename the package from pdfium-linux-arm to pdfium-linux-arm32? This would also be more consistent with the other targets...

Would it be possible to add properties to the generated DLLs?
I am mostly interested in the versions.
Currently, they are empty as per the screenshot below.

Is it possible to include also static libraries or some easy guide how to build them?

Hi Team,

Thanks for the simplyfying the build process for pdfium, the compiled x64 windows builds on your main page (without XFA and V8) are around 4mb unzipped, i have used the build script turned off V8 and XFA but am always getting the size of 12mb , how do i get it down to the 4mb ? what am i doing wrong?

Cheers
Glen

Is it possible to build as static library on Mac? thx!

Hello,

I tried to use the xfa enabled build (using a C# wrapper)

I initialised this way https://github.com/bblanchon/pdfium-binaries#how-to-use-javascript-v8-enabled-binaries for ressources.
Then after loading the document i call FPDF_LoadXFA but it return false :(

I use the pdf attached on this pdfium resolved bug ( https://bugs.chromium.org/p/pdfium/issues/detail?id=1081 ), i can't render the form values.

Do i missed something ?

Thanks
Whiletru3

I am trying to build the Pdfium library for a UWP application and when I run the build script, it does not give any build errors but the pdfium.dll.lib & pdfium.dll files are not generated. I have made couple of minor changes to the build script, apart from that there are no other changes.

set GYP_MSVS_VERSION=2019 set CONFIGURATION=Release set PLATFORM=x64 set PDFium_BRANCH=master set PDFium_V8=disabled

: Clone git.exe revert call gclient config --unmanaged %PDFium_URL% || exit /b call gclient sync --force --reset || exit /b

: Checkout branch (or ignore if it doesn't exist) echo on cd %PDFium_SOURCE_DIR% git.exe checkout %PDFium_BRANCH% && call gclient sync --force --reset

I am not familiar with Pdfium library and could you please give some guidance with the issue I am facing?

This is the output I am getting from the PS.

Is there a special reason why no Windows Binarys released since Versions 4194 !?

Would it be possible for this project to build binaries for Linux platforms that use the musl libc implementation rather than glibc (e. g. Alpine Linux)? (I got into this topic because I recently noticed that support for musllinux wheels got added to PyPI, cf. PEP 656.)

Having issues building this on arm64. Is any work planned to support this?

Thank you in advance. Am I wrong to build it on Windows 10 Pro x64? The error information listed below:

D:\PDF\repo\pdfium\pdfium-build-windows>call curl -fsSL -o depot_tools.zip https://storage.googleapis.com/chrome-infra/depot_tools.zip || exit /b

D:\PDF\repo\pdfium\pdfium-build-windows>call 7z -bd -y x depot_tools.zip -oD:\PDF\repo\pdfium\pdfium-build-windows\depot_tools || exit /b

7-Zip 19.00 (x64) : Copyright (c) 1999-2018 Igor Pavlov : 2019-02-21

Scanning the drive for archives:
1 file, 23146751 bytes (23 MiB)

Extracting archive: depot_tools.zip

Path = depot_tools.zip
Type = zip
Physical Size = 23146751

Everything is Ok

Folders: 104
Files: 735
Size: 27617004
Compressed: 23146751

D:\PDF\repo\pdfium\pdfium-build-windows>set PATH=D:\PDF\repo\pdfium\pdfium-build-windows\depot_tools;C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0;C:\Program Files\PowerShell\7;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\WINDOWS\System32\OpenSSH;C:\Program Files\PowerShell\7;C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit;C:\Program Files\TortoiseSVN\bin;C:\Program Files\dotnet;C:\Users\Neusoft\AppData\Local\Microsoft\WindowsApps;C:\Program Files\CMake\bin;C:\Program Files\TortoiseGit\PortableGit\bin;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29333\bin\Hostx64\x64;C:\Program Files\7-Zip;C:\Program Files (x86)\ninja-win;C:\Program Files\Java\jre1.8.0_202\bin;C:\msys64\mingw64\bin;

D:\PDF\repo\pdfium\pdfium-build-windows>set DEPOT_TOOLS_WIN_TOOLCHAIN=0

D:\PDF\repo\pdfium\pdfium-build-windows>where rc.exe || exit /b
C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\rc.exe

D:\PDF\repo\pdfium\pdfium-build-windows>call gclient config --unmanaged https://pdfium.googlesource.com/pdfium.git || exit /b
Syncing projects: 100% (26/26), done.
Running hooks: 100% (16/16), done.

D:\PDF\repo\pdfium\pdfium-build-windows>cd D:\PDF\repo\pdfium\pdfium-build-windows\pdfium

D:\PDF\repo\pdfium\pdfium-build-windows\pdfium>git.exe checkout && call gclient sync
Syncing projects: 100% (26/26), done.
Running hooks: 100% (16/16), done.
1 file(s) copied.
Checking patch BUILD.gn...
error: while searching for:
]?
}?
?
component("pdfium") {?
libs = []?
configs += [ ":pdfium_strict_config" ]?
public_configs = [ ":pdfium_public_config" ]?

error: patch failed: BUILD.gn:160
error: BUILD.gn: patch does not apply
Checking patch public/fpdfview.h...
error: while searching for:
// Dictionary value types.?
typedef int FPDF_OBJECT_TYPE;?
?
#if defined(COMPONENT_BUILD)?
// FPDF_EXPORT should be consistent with |export| in the pdfium_fuzzer?
// template in testing/fuzzers/BUILD.gn.?
#if defined(WIN32)?
#if defined(FPDF_IMPLEMENTATION)?
#define FPDF_EXPORT __declspec(dllexport)?

error: patch failed: public/fpdfview.h:176
error: public/fpdfview.h: patch does not apply
PS D:\PDF\repo\pdfium\pdfium-build-windows>

I have error : dlopen failed: library libabsl.cr.so not found when launch app with android studio