Support for static linking in ASP.NET Core Blazor WebAssembly

[sungaila]

ASP.NET Core Blazor WebAssembly needs pdfium/out/obj/libpdfium.a to statically link PDFium into a project. This PR changes the workflow and nuspec to accomplish this.

• The build artifact pdfium-wasm.tgz includes libpdfium.a now.
• bblanchon.PDFium.WebAssembly.nuspec includes libpdfium.a as well.
  • The NuGet package structure follows SkiaSharp.NativeAssets.WebAssembly.
• Automatically adds NativeFileReference via a prop file.

  • WebAssembly-specific dependencies aren't referenced automatically and must be referenced manually as NativeFileReferences. Package authors can choose to add the native references by including a .props file in the package with the references.

  • See Package native dependencies in a NuGet package.
• pdfium.wasm is still included in the NuGet package for previous use cases (see #94).
• Add wasm to the NuGet tag list because searching for "pdfium wasm" on nuget.org yields no results. :-)
• This solves #122 and @jerbob92's input on this PR is very much appreciated.

Considerations

The pdfium tgz archives should contain platform and architecture specific PDFium binaries. Putting libpdfium.a into pdfium-wasm.tgz feels wrong but it is needed for static linking via wasm-ld. Maybe this should be put into a separate archive? Or maybe it shouldn't be archived at all and be available for the NuGet packaging only.

[bblanchon]

Thanks!

Putting libpdfium.a into pdfium-wasm.tgz feels wrong but it is needed for static linking via wasm-ld. Maybe this should be put into a separate archive? Or maybe it shouldn't be archived at all and be available for the NuGet packaging only.

Let's go with this PR; we'll change the packaging when we get a better understanding of the problem.

[jerbob92]

As far as I know you normally don't ship the .a because it is byte code and not an end product that you can use, it's only used as an intermediate product to link into other projects. I could be wrong here but the file might be very specific to the Emscripten / LLVM version.

[sungaila]

I could be wrong here but the file might be very specific to the Emscripten / LLVM version.

I think you are correct about that. The SkiaSharp WebAssembly NuGet package contains multiple folders with libSkiaSharp.a files. The folder names correspond to the Emscripten version.

The MSDN documentation says:

Prebuilt dependencies typically must be built using the same version of Emscripten used to build the .NET WebAssembly runtime.

I could use the current libpdfium.a just fine but this might change in the future when new Emscripten versions are released.

[bblanchon]

We had issue #145 today with a user complaining that libpdfium.a wasn't built with -pthread. Long story short, @jerbob92 and I are wondering if shipping the static library is a good idea since we would have to build many variations to satisfy everyone. @sungaila, do you see a way I could remove the static lib from the public tarball, but you'd still be able to build your project somehow?

[sungaila]

@bblanchon Ideally, I'd like to have a NuGet package like SkiaSharp.NativeAssets.WebAssembly where libpdfium.a is built with multiple combinations of emsdk versions and compiler flags. .NET 7 needs emsdk 3.1.12 and .NET 8 needs emsdk 3.1.34.

So they are doing exactly that: build many variations to satisfy everyone.

But since this cannot be done without major restructuring of existing workflows and build scripts, I would have no problem to remove libpdfium.a from the tarball ... for now.

Thanks to #143 I can easily build libpdfium.a in my own fork myself.

[bblanchon]

Am I reading this correctly: removing libpdfium.a from the tarball won't affect you?

[sungaila]

@bblanchon Yes, but please keep in mind that simply removing libpdfium.a from the lib folder might break the wasm NuGet package.

[bblanchon]

Thanks for the warning, @sungaila. I think I will mostly revert this PR.

@jerbob92, I'm going to remove libpdfium.a from the tarball. That's what you wanted, right?

[jerbob92]

@bblanchon it doesn't affect me in any way, but I think distributing the .a file gives people the idea that they can use it and will probably lead to more support questions in the future, since the usability of it depends a whole lot on the build environment of the user (emscripten version, build flags). That's why I would remove it.

Perhaps there is a way to help the people that need the .a file by making this project directly usable in their build system, but that is probably out of the scope of this repo.

[bblanchon]

Agreed. @sungaila, let me know if you need to add more options to the GitHub workflow. Maybe an "is_static" flag?