fasterthanlime

Dec 31, 2021 17 min #build-systems · #autotools · #cmake · #pkg-config · #ftl-infra

A static poppler build: the easy way

Thanks to my sponsors: Isak Sunde Singh, Olivia Crain, ShikChen, Zachary Thomas, traxys, Toon Willems, Yves, Michael Alyn Miller, Max Bruckner, Richard Pringle, James Brown, Michal Hošna, Kamran Khan, Boris Dolgov, Herman J. Radtke III, Jan-Stefan Janetzky, Marco Carmosino, Egor Ternovoi, Scott Sanderson, Damir Vandic and 267 more Isak Sunde Singh, Olivia Crain, ShikChen, Zachary Thomas, traxys, Toon Willems, Yves, Michael Alyn Miller, Max Bruckner, Richard Pringle, James Brown, Michal Hošna, Kamran Khan, Boris Dolgov, Herman J. Radtke III, Jan-Stefan Janetzky, Marco Carmosino, Egor Ternovoi, Scott Sanderson, Damir Vandic, Chris Emery, bbutkovic, Lena Schönburg, Timothée Gerber, Matt Jadczak, Yann Schwartz, Alex Rudy, Chris Sims, Max von Forell, Horváth-Lázár Péter, Matt Jackson, Ahmad Alhashemi, Matt Campbell, Gioele Pannetto, Mark, Joseph Montanaro, Elnath, Julius Riegel, Yuriy Taraday, Ives van Hoorne, Matěj Volf, Benjamin Röjder Delnavaz, Diego Roig, Geoffroy Couprie, Steven Pham, Zeeger Lubsen, belzael, WeblWabl, James Rhodes, Helge Eichhorn, Zaki, Ryan, Mario Fleischhacker, Tiziano Santoro, Marcus Brito, Josh Triplett, Daniel Strittmatter, Lennart Oldenburg, qrpth, Marcin Kołodziej, Valentin Mariette, Stephan Buys, xales, Ross Williams, Beat Scherrer, Colin VanDervoort, Mathias Brossard, Scott Steele, C J Silverio, Justin Ossevoort, Lev Khoroshansky, Torben Clasen, Alex Krantz, Jelle Besseling, Jan De Landtsheer, L0r3m1p5um, Luke Yue, hgranthorner, Leigh Oliver, jatescher, Simon Menke, callym, Andy Gocke, Daniel Silverstone, Santiago Lema, medzernik, Samit Basu, Aleksandre Khokhiashvili, Enrico Zschemisch, Dylan Anthony, David Souther, prairiewolf, Jack Maguire, anichno, Laine Taffin Altman, avborhanian, Michael, kuerbsikakteen, old.woman.josiah, Paul Schuberth, Mattia Valzelli, Adam Gutglick, Chris, Ronen Ulanovsky, Tanner Muro, Malik Bougacha, Tobias Bahls, Matt Heise, teor, Andrew Neth, Chirag Jain, Cole Tobin, Adam Lassek, Alejandro Angulo, Radu Matei, Yufan Lou, Niels Abildgaard, Raphaël Thériault, SeniorMars, std__mpa, Alan O'Donnell, Vincent, notryanb, Berkus Decker, Luke Konopka, Dom, Ronen Cohen, Mateusz Wykurz, James Leitch, Guillaume E, Raine Godmaire, Jesse Luehrs, Philipp Gniewosz, Vladimir, Makoto Nakashima, Sam Leonard, Chris Biscardi, Nicholas, Jim, Duane Sibilly, Dirkjan Ochtman, Guillaume Demonet, Astrid, Elendol, Mason Ginter, Victor Song, Julian Schmid, Senyo Simpson, Johnathan Pagnutti, Paul Horn, Paige Ruten, compwhizii, Urs Metz, you got maiL, ZacJW, (18D)eezNuts, Nicolas Riebesel, Das Gürteltier, playest, Marcus Griep, Hadrien G., Tyler Schmidtke, Dimitri Merejkowsky, Philipp Hatt, Romain Kelifa, Richard Stephens, Aljaz Erzen, Integer 32, LLC, Ben Mitchell, Evan Relf, Cass, clement, Marky Mark, Cole Kurkowski, Paul Marques Mota, jer, Antoine Rouaze, ofrighil, Walther, Jake Demarest-Mays, Pete LeVasseur, Beth Rennie, Romain Ruetschi, John Horowitz, Johan Saf, Joshua Roesslein, ACRL, Manuel Hutter, Jack Duvall, Matthew T, Braidon Whatley, Geoff Cant, Tabitha, Noel, Geoffrey Thomas, Mikkel Rasmussen, Christoph Grabo, Wyatt Herkamp, Aalekh Patel, Ivo Murrell, Borys Minaiev, Thor Kamphefner, Antoine PESTEL-ROPARS, Jörn Huxhorn, AdrianEddy, Guilherme Neubaner, Sawyer Knoblich, budrick, Thehbadger, Morgan Rosenkranz, Jacob Cheriathundam, Kai Kaufman, Lyssieth, Aiden Scandella, Marty Penner, Blake Johnson, Andy F, Zoran Zaric, Josiah Bull, Christopher Valerio, Neil Blakey-Milner, Peter Shih, Bob Ippolito, Eugene Bulkin, Shane Lillie, Henrik Tudborg, Mark Tomlin, Luiz Ferraz, Chris Walker, G, pinkhatbeard, villem, Sean Bryant, Guy Waldman, Sonny Scroggin, Corey Alexander, David Cornu, Rufus Cable, David Barsky, Xavier Groleau, Matthew Planchard, Mike Cripps, Ian McLinden, Tyler Bloom, Ben Wishovich, Romet Tagobert, genny, Olly Swanson, Lucille Blumire, Garret Kelly, Gorazd Brumen, John VanEnk, Dennis Henderson, Sindre Johansen, Michał Bartoszkiewicz, Max Heaton, Jonathan Adams, Xirvik Servers, Marie Janssen, Christian Bourjau, Daniel Wagner-Hall, Sarah Berrettini, Ula, Michael Mrozek, David E Disch, Seth, Mike English, Marcus Griep, Marc-Andre Giroux, Sylvie Nightshade, Mark Old, Chris Thackrey, Jon Gjengset, Brandon Piña, Elijah Voigt, David White, René Ribaud, Daniel Papp, Pete Bevin, hardfist, Antoine Boegli, Jean-David Gadina, Wojciech Smołka, Kristoffer Winther Balling, Andronik, Nyefan, Kyle Lacy

So! Now our asset processing pipeline is almost complete. But we’ve just traded dependencies against CLI tools, for dependencies against dynamic libraries:

Whew, that’s a LOT of dependencies.

It is. There’s a lot of stuff in there we don’t strictly need, they’re optional dependencies in the poppler dependency tree: we never need cairo to render to X11/xcb for example, only to an SVG surface.

On Linux, this mostly means installing a lot of different packages just to get our binary running. And those packages are named differently depending on which Linux distribution you’re using: I use Fedora, Ubuntu and ArchLinux on a regular basis. Their contents can be different too, again, some package maintainers make Executive Decisions and that makes it really hard to ship cross-distro packages.

This is where folks who work on AppImage, snapcraft or flatpak would usually come in and pitch their solution to that problem.

These are all fine for various usecases, they each make their own compromises, and I’m familiar with them - I’m making an informed decision not to use them.

Similarly, if you’re a Nix aficionado, I’m super happy for you, but go write your own article! I’ll retweet them, too! Today we’re just learning how to build / link / distribute software for internal use.

On Windows, I’d have to be careful to distribute a bunch of .dll files alongside the .exe, which can get messy real fast if you have a ~/bin folder where you just throw all your CLI tools.

Anyway, we can address both problems by just making our own build of poppler as a static library.

Before we do, let’s record the size of the pdftocairo binary, before and after stripping, when it’s linked dynamically against poppler & friends:

During my tenure as “chief fucking around and finding out officer”, I’ve built software from sources “manually” a ton. If you somehow need to get good at this and have a month of free time, Linux From Scratch might be a nice thing to hyperfocus on.

For poppler, I determined that these were the dependencies I needed to build (in order):

• pcre
• libffi
• zlib
• libpng
• glib
• fontconfig
• freetype
• pixman
• cairo
• poppler

One could argue harfbuzz is missing from that list, but things went fine without it. Because in this case, the input is the result of Chrome’s “Print to PDF” feature, the text is already laid out, and so I don’t think harfbuzz is actually needed here.

I made a bunch of bash scripts for this, which is one tiny step up from “typing everything into a terminal once”.

They all have the same structure: we’ll follow the script for pcre for example.

So that’s with autotools! Not too bad, all things considered.

That reminds me of a tweet by Tim Martin:

I saw a book entitled “Die GNU Autotools” and I thought “My feelings exactly”. Turns out the book was in German.

The one surprising thing is this line:

And that line exists because… the default Rust toolchain tries to make position-independent executables. We discussed this in Position-independent code, but back then we were hyperfocused on learning about ELF. Here we’re just hitting it in the real world!

Position-independent code is generally a good thing, but with most C build systems / compilers, you have to explicitly opt into it, unless you’re building shared objects (.so). Since we’re building static library archives here (.a), we have to tell the C compiler that we intend for that code to eventually be linked into a position-independent executable (a PIE).

As a result, it’ll use a different set of relocations, that are compatible with position-independent executable. If we forget that part, we’ll just get an error at link-time, where the linker will be like “uhh yeah I can’t make a PIE with those relocations”. It’s not as bad as silently building an executable that panics at runtime.

And autotools is relatively hands-off here: it’s mostly concerned with making sure it doesn’t have to enable a hundred workarounds, that are only needed if you’re building for HP-UX or Irix or something.

I mean, technically libtool has a thing where it’ll generate both PIC and non-PIC objects, and there’s the --with-pic option but eh… I don’t super trust it.

Other build systems have other ways to specify that you want position-independent code!

Here’s a cmake example:

The position-independent flag here is -DCMAKE_POSITION_INDEPENDENT_CODE=True.

Here’s an interesting distinction between autotools and CMake: although they both have this “configure” stage, where they generate some more files that will be required to build, CMake actually provides a --build (and an --install) option!

Whereas autotools had us running make by hand. Which is fine on Linux, macOS, or even MinGW on Windows. But on Windows, I want to use MSVC. Some projects ship a .sln (Visual Studio Solution) file directly, but these are not entirely portable across Visual Studio versions, even though they do their best to “upgrade” it when you open it.

So, if you were wondering why in the world people bothered with systems like CMake, that’s why: not everything is Linux, not every C compiler is GCC, not every build systems is GNU make. It’s super useful to have a tool that drives the whole process, and lets you use MSVC as a C compiler, or ninja as a build system, for example.

And Meson is another one of these!

Usage is really similar to CMake, here’s my build script for freetype:

As you can see, there’s also a standard way to enable/disable features (like brotli, bzip2, etc.), pick the installation prefix (--prefix), the build target (--default-library), and some built-in options to enable position-independent code (b_staticpic and b_pie: pretty sure the latter is not needed here, but ah well).

And so, having written all my build scripts, and an all.sh script to call them all in order, I’m ready to make my static build. Here’s an asciinema of it: it completes in a little over a minute on a Ryzen 5950X with 128GB of RAM and a decent NVMe SSD (on Fedora 35 inside VMWare Workstation Player with a Windows 11 host):

I find it really fun to watch it go! You can see some colors around the Meson and CMake parts. It’s so nice!

In the end, we have 150MB’s worth of libraries in our prefix:

How do we link about this? Thanks to pkg-config!

The Fedora package for poppler-glib installed the /usr/lib64/pkgconfig/poppler-glibc.pc, which contains all the libraries and flags required to use it:

And now that we’ve built and installed poppler-glib into our own prefix, we have a /home/amos/bearcove/poppler-build/prefix/lib64/pkgconfig file

(Note that the version we built is more recent than the version Fedora 35 ships!)

pkg-config is relatively straightforward to use “manually”. To show it off, I made a sample C program:

Trying to compile it with gcc the naive way doesn’t work, because include paths are not set:

But even setting those include paths aren’t enough:

…because now we’re missing the libraries. And this is what pkg-config solves!

But this picks up the system / distro-installed .pc files. If we want to use the prefix we just made, we need to set the PKG_CONFIG_PATH environment variable.

I’ve just shown the --cflags flag which is necessary for compiling C files (it sets defines and includes paths, mostly), and then there’s --libs, which is necessary to link everything together.

Here’s what linking dynamically (with the system packages) would look like:

And now statically (with our own prefix):

Because in our case we’re doing static linking, we also probably want to use the --static flag, which tells pkg-config to “be more aggressive when computing dependency graph (for static linking)”, and because we don’t want to accidentally end up dynamically linking against a system library, we can specify --env-only, which tells pkg-config to “look only for package entries in PKG_CONFIG_PATH”.

This doesn’t actually make a difference for glib-2.0:

But it does for cairo, for example!

Without --static, it only bothers specifying -lcairo, I’m guessing because it assumes by default we’re linking dynamically, and libcairo.so itself depends on other libraries:

There’s no such concept with .a archives (static libraries). They’re just a bunch of .o files:

Cool Bear's hot tip

“GNU ar” is most probably named for “archive”, and it’s part of binutils. The t flag prints a “lisT” of entries, and v is “Verbose”.

So, when we specify --static (and --env-only for good measure), pkg-config lists dependencies explicitly:

So, to link our sample C program statically against our libraries, all we need to do is grab the output of pkg-config --cflags and pkg-config --libs and use it for the appropriate build stages:

The compile step ends up looking like this:

And the link step, like this:

(With the actual prefix replaced with ${PREFIX} for readability).

Specifying poppler-glib wasn’t enough in this case, adding gio-2.0, fontconfig and libpng was still needed. This feels like a bug in .pc files, but then again, static linking is starting to feel like a lost art: mainstream distributions like Ubuntu and Fedora are definitely focused on dynamic linking above all else.

Here’s another cool tip: pkg-config can generate a graphviz (.dot) file to graph dependencies:

It seems cairo has basically no dependencies in that graph, whereas in reality, it definitely has a bunch:

Looking closer, it appears those are listed, but as “private” dependencies:

So maybe it’s just the graph generation that’s broken, which explains why we need to specify fontconfig by hand, but not freetype2.

Anyway! Let’s get back on track.

With all that effort, our sample C program has almost no dynamic dependencies:

Similar to another randomly-chosen Rust CLI program:

The dependencies there are:

• linux-vdso.so: a “virtual” dynamic shared object to make some syscalls faster (like gettimeofday)
• libgcc_s.so: some GCC builtins, like _Unwind_Resume, __popcountdi2, etc.
• libm.so: math functions, like tan, sqrtf32, etc.
• libc.so: the standard C library, in this case, glibc
• ld-linux-x86-64.so.2: the dynamic linker/loader, see this whole series

And the good news is: the -sys crates for various gnome/glib-adjacent libraries use pkg-config to know what to link against!

Let’s look at what gtk-rs/gir generated for poppler-rs/sys/build.rs for example:

This uses the system-deps crate, which README says it supports pkg-config dependencies by looking at the Cargo.toml.

Do we have anything there?

We do!

And so if we build with no particular options, we can spy on cargo to see what it executes..

Cool Bear's hot tip

strace tracks syscalls: in this case we want to track execve calls (executing another program), we want to “follow forks” (-ff), ie. spy on all processes created by the top-level cargo, such as compiled build scripts, and we want to output the logs, per-PID (process identifier), to /tmp/cargo-build.PID files.

Cool Bear's hot tip

rg is ripgrep — it’s excellent.

Hilariously, we can see that system-deps ends up trying every possible path for pkg-config, starting with ~/.cargo/bin, then ~/.local/bin, then ~/.fly/bin, etc. It does so for every invocation.

There could probably be benefits in looking it up once and just using that path, if someone feels like doing an easy, low-impact-but-nice PR!

So, because we know cargo ends up invoking pkg-config (and environment variables are inherited by child processes, unless that behavior is specifically disabled), we can just set PKG_CONFIG_PATH as before, and everything sh-

…everything is NOT working, because, remember, a bunch of packages are actually missing!

So we got a couple options here — one is to make our own build.rs script for pdftocairo. This is relatively simple to set up:

And then the build succeeds!

As promised, it has “virtually no external dependencies”:

And also, deliciously chonky:

(It was 48M when using dynamic linking).

Although, we have ways to make it smaller. By compressing debug sections:

(That variant was 16M with dynamic linking).

Or stripping debug info altogether:

And that was just 5.3M with dynamic linking. So yeah! All that code isn’t free, but we have a freaking PDF to SVG converted in a single, relatively self-contained binary now!

Running ./target/debug/pdftocairo yields the same result as before. Yay!

Cool Bear's hot tip

We talked earlier about having a couple options: another one is to patch the .pc files ourselves. But this isn’t great either, because system-deps defaults to dynamic linking and patching it the “proper” way would involve upstreaming patches to a bunch of crates.

Once again, the world as a whole has kinda given up on static linking, so we’re on our own here - unless we look into AppImage/snapcraft/flatpak.

What did we learn?

In the world of C/C++ libraries, as far as build systems go, it’s kind of a free-for-all. There’s the old-school autoconf users, the great CMake / Meson divide, and then Bazel, Buck, and many others.

We made everything more complicated by really, really wanting a static build, which very few people care about, so we had to jump through more hoops than one would normally have to.

pkg-config is a tool that outputs the required compiler flags for compiling and linking against C/C++ libraries. It ships with Linux distributions and normally looks in a system prefix, like /usr/lib64/pkgconfig. But it also works with “custom prefixes” like we did.

Here too, static linking complicates things a little.

Comment on /r/fasterthanlime

Here's another article just for you:

The case for sans-io

Feb 07, 2025

26 min #zip · #rust · #async exclusive

The most popular option to decompress ZIP files from the Rust programming language is a crate simply named zip — At the time of this writing, it has 48 million downloads. It’s fully-featured, supporting various compression methods, encryption, and even supports writing zip files.

However, that’s not the crate everyone uses to read ZIP files. Some applications benefit from using asynchronous I/O, especially if they decompress archives that they download from the network.

Read more