WASM with pthread support?

[mmarczell-graphisoft]

When trying to link the wasm into a multithreaded program, I get this linking error:

error: --shared-memory is disallowed by jpegmodule.o because it was not compiled with 'atomics' or 'bulk-memory' features.

This indicates it was compiled without pthread support. Can we get a version compiled with pthread support?

[bblanchon]

Hi @mmarczell-graphisoft,

Thank you for reporting this issue.

Emscripten's documentation says:

Pass the compiler flag -pthread when compiling any .c/.cpp files, AND when linking to generate the final output .js file.

So, I did, and the build went fine except for this warning returned by em++:

-pthread + ALLOW_MEMORY_GROWTH may run non-wasm code slowly, see https://github.com/WebAssembly/design/issues/1271 [-Wpthreads-mem-growth]

@mmarczell-graphisoft, please try the artifact produced by build 6955160637

@jerbob92, do you think passing -pthread is the right move?

Best regards, Benoit

[mmarczell-graphisoft]

@bblanchon the artifact successfully links and generates a simple pdf in my usecase.

[bblanchon]

Cool! Thanks for the fast update, @mmarczell-graphisoft.

I'll merge this change as soon I as get the green light from @jerbob92.

[jerbob92]

@mmarczell-graphisoft Are you statically linking in the build like in https://github.com/bblanchon/pdfium-binaries/issues/122?

@bblanchon I don't think we want to add this compile flag to pdfium-binaries, pdfium does not need it to run/compile, if we are going to add any Emscripten flag because another compiled program/library uses it and it causes pdfium to be unable to link in, where does it stop? It's also not possible because not all flags are compatible with each other. You are going to run into this issue someday. I think statically linking for WASM should only be done when you are in full control of the compile process and building the .a file yourself, it's why I'm also not a fan of adding the libpdfium.a to the release.

[bblanchon]

Indeed, I didn't remember that we ship the static library for this one. Why are we doing this; the .wasm is not enough?

[mmarczell-graphisoft]

Yes, I am statically linking.

I understand your concerns, and this logic may even extend to other parameters like the emsdk version. I can imagine a situation where for example the C or C++ standard library is updated in a newer emsdk, and it might cause issues if the library and the application are built with different emsdk versions. But that is a concern with all platforms and compiler version updates, not just Emscripten.

I don't understand how I'm supposed to actually use the .wasm file in my application though.

[jerbob92]

@bblanchon This was added in https://github.com/bblanchon/pdfium-binaries/pull/123, to support using it in ASP.NET Core Blazor WebAssembly, because apparently that only supports statically linking in libraries.

@mmarczell-graphisoft Yeah, it requires your emscription version to match the one of pdfium-binaries, and as you have noticed also other things, like certain compile flags.

How you would normally use the .wasm is run it in a virtual machine/runtime and then interact with it using guest function calls. The .wasm binary exports all of the pdfium functions as callable functions that you can call from code using the vm/runtime.

For example, see my implementation in Go here: https://github.com/klippa-app/go-pdfium/blob/main/internal/implementation_webassembly/fpdf_transformpage.go It uses the Wazero runtime to run Wasm from Go, I can then call the exported functions with ExportedFunction("{function-name}").Call({arguments}). If you are trying to compile C/C++ code that directly interacts with pdfium from that code, you should probably compile pdfium together with the rest of your project.

[jerbob92]

@bblanchon just thought of a side effect of this change, probably the wasm standalone build won't work anymore on virtual machines that don't support threads (like the one I am using) .

[bblanchon]

I removed libpdfium.a as discussed here and in #123.