bblanchon / pdfium-binaries

📰 Binary distribution of PDFium

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

building for v8 for mac x64 - broken?

schmitch opened this issue · comments

Hello, I forked your repo to build for v8 (xfa support) and tried to run a build with mac:

I basically created a small rust program, that works without v8 or your libraries, but once I enable v8 I get the following error, when loading the dylib:

ld: warning: ignoring file /Users/schmitch/projects/envisia/finder/incubator/pdfium-finder/pdfium_lib/lib/libpdfium.dylib, building for macOS-x86_64 but attempting to link with file built for unknown-unsupported file format ( 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 )
          Undefined symbols for architecture x86_64:

This is the final release:

https://github.com/schmitch/pdfium-binaries/releases/tag/chromium%2F4785

any ideas?

I'm building with rust, basically I changed the following library a little bit:

to also include new functions

Hi @schmitch,

I didn't build the v8 versions for a while because they are very long to build and very few people seem to be interested.
I plan on restoring them as soon as I manage to build the non-v8 versions for all supported platforms.

Unfortunately, you didn't show enough of the log and the actual name of the undefined symbols are missing.
I tried to look a the log of your build but couldn't find the quoted log lines.

Please share the log lines after Undefined symbols for architecture x86_64 and maybe it will give me a clue about what's wrong.

Best regards,
Benoit

PS: did you see this issue on other platforms as well?

@bblanchon sadly no, somehow I also got past the linking?! maybe I forgot to run a clean build and the rust build tool cargo did cache the symbols I do not know....

However now I get a runtime panic:

#
# Fatal error in , line 0
# Check failed: platform_.
#
#
#
#FailureMessage Object: 0x7ff7be881630[1]    56054 abort      cargo run

could not yet figure out, but it happens in FPDF_InitEmbeddedLibraries however the string I'm passing looks correct, because since I use a "wrong" one it also prints an additional warning: "Failed to open startup resource 'WRONG_PATH/snapshot_blob.bin'."

will try on linux in a few days

@TcT2k added this function, maybe he can help?

Haven't looked into pdfium for a while, but I might have a look at it in the coming weeks. I would assume that this isn't x86_64 specific but would also occur on arm64 builds with macOS.

btw. I also tested Linux and the same error basically happens there on x64

#
# Fatal error in , line 0
# Check failed: platform_.
#
#
#
#FailureMessage Object: 0x7ffdd5bed4f0Aborted (core dumped)

I guess the patch needs to be changed to also initalize the platform:

https://chromium.googlesource.com/v8/v8/+/branch-heads/6.8/samples/hello-world.cc

i.e. to:

// Initialize V8.
v8::V8::InitializeICUDefaultLocation(argv[0]);
v8::V8::InitializeExternalStartupData(argv[0]);
std::unique_ptr<v8::Platform> platform = v8::platform::NewDefaultPlatform();
v8::V8::InitializePlatform(platform.get());
v8::V8::Initialize();

I try it and make a PR if it works.

it would also be cool if the v8 enabled stuff would be built automatically (does not need to be linked, just have it under releases)

it would also be cool if the v8 enabled stuff would be built automatically (does not need to be linked, just have it under releases)

What do you mean?

like if https://github.com/bblanchon/pdfium-binaries/releases/tag/chromium%2F4818 would also contain the builds with v8 enabled, at least for some platforms.

That's the plan. As I told you, I wanted to get all the combinations right before restoring v8.
I recently added the ARM build for Windows and I hesitate to add a WASM build as requested in #28.

V8 builds still seem to be broken.

The issues I ran into:

  • steps/08-test.sh fails with V8 builds.
  • steps/09-pack.sh does not include all required shared libraries.