Ok, I've looked into this a bit.

Short answer: yes, it's possible to statically link to Pdfium at compile time, and it's no problem to implement static bindings for pdfium-render.

Longer answer: yes, it's possible, but.... :)

I am not a compiler expert, so am happy to be corrected on this. But my understanding is that, when you compile a library (like Pdfium, for instance), you make a decision at compile time as to whether your library will be used for static linking or dynamic linking. (On Linux, this results in the compiler generating you a .a file for static linking, or a .so file for dynamic linking; on Windows, a .lib file for static linking, or a .dll for dynamic linking; on macOS, a .a file for static linking, or a .dylib for dynamic linking.) Once you have a static library, you can only link it statically into an executable; you can't rework it so you can link to it dynamically at runtime. Likewise, once you have a dynamic library, you can only link to it dynamically from an executable; you can't rework it so you can statically link to it at compile time.

Herein lies the problem. In order to statically link to Pdfium at compile time (and thus embed it in your executable), you would need a static library build of Pdfium. And as far as I can tell, most of the pre-built Pdfium libraries available aren't built statically; they're built for dynamic linking. For instance, all the builds I currently recommend at https://github.com/bblanchon/pdfium-binaries/releases are dynamic libraries - they can't be used for static linking.

The repo https://github.com/paulocoutinhox/pdfium-lib/releases does publish static builds of Pdfium for iOS and macOS, and I think the reason they've done this is that it's much easier to persuade Xcode to link against a static build at compile time than to use a dynamic library at runtime. But all other platform releases I can find publish dynamic libraries, not static libraries.

I think it's highly likely you will need to build Pdfium statically yourself if you want to do this. The good news is there are build scripts for doing so in those two repos I mentioned; you just need to change the build flags to generate a static library rather than a dynamic one. (I think it's as simple as setting both the "pdf_is_standalone = true" and "pdf_is_complete_lib = true" ninja build flags.)

So, I'm going to add the option for binding to a statically-linked Pdfium library to pdfium-render, because it's genuinely helpful to have that option when compiling for iOS and macOS, and pre-built static libraries of Pdfium for those platforms are already available. But for all other platforms, I think you're still better off using dynamic linking and just shipping a libpdfium.so alongside your executable, because to link statically you're probably going to have to build Pdfium yourself.

I think the idea of having pdfium-render build Pdfium for you is outside the scope of this crate. I am open to having a crate feature where pdfium-render sends a message to cargo to link in a pre-built Pdfium static library, since this means you wouldn't need to muck around with a custom build script for your Rust application. But actually building Pdfium as a static library in the first place - you need to do that yourself separately, or find a source online where they already publish static builds of Pdfium. (Let me know if you find such a source, I'd be interested!)

Statically linking pdfium #12

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions