Static linking

While I was working on a new initramfs generator for Carbs, I was once again reminded of the advantages of static linking software. Previously, I was using some really dumb script that was just basically using the package manager as a library for building the whole initramfs system from scratch. This system structure was completely statically linked, and the whole thing weighed around 1.3MiB.

Now, while rd (the small script that I had written) was good enough for me, it wouldn’t be a fit to distribute with the system. It doesn’t deal with dynamic binaries, kernel modules or library installation. So I have written this script that deals with those (kernel modules aren’t done yet, though).

The issue with build systems today are that the binaries are built dynamically unless you build the whole thing static. As long as there are shared libraries, the binaries will be dynamic as well. That’s why the core repository of Carbs still contains dynamic binaries for gcc, binutils, util-linux and some other packages.

The size of the new image with exactly the same binaries is a whopping 1.9MiB. While a size increase of 600KiB might not seem like a huge deal, I just want to tell you that busybox is static in both images, leaving ONLY TWO binaries that I install to my image; fsck and e2fsck. By switching from a static binary to dynamic + lib for only two programs, you require 600 KiB more space, and I have been talking about a gzip compressed cpio archive throughout this whole post.

This page in plain-text