Static builds

[wong-justin]

I would like to support static binaries, just like chafa. This means I need to statically link glib during compilation. I've had trouble doing that, both on my machine and cloud images.

A few people have talked about linking glib statically (see below). I haven't found a reproducible static build script unfortunately.

I think I need to use a decent/recent glib version, maybe find the important .c files, maybe write a few lines of patches, and definitely fiddle a lot with GitHub Actions.

Here's the resources I've found so far:

---

https://github.com/hpjansson/chafa/issues/41#issuecomment-650351621

... it'd be possible to drop in a cut-down GLib similarly to what pkg-config does: https://gitlab.freedesktop.org/pkg-config/pkg-config/

Someone built chafa with emscripten and vendored glib: https://github.com/oakes/chafa. The same person also built chafa/glib with a Nim script: https://github.com/ansiwave/ansiwave/blob/master/src/ansiwavepkg/chafa.nim

https://github.com/hpjansson/chafa/issues/72#issuecomment-1172854807

... cross compile from WSL2, or use MSYS2. Either of them will provide a Unix-style development environment ... I'd suggest going with MSYS2, since they have prebuilt packages for zlib, glib and freetype, which saves some time building it from scratch. Either way, the build process should be pretty much the same as with Linux.

The author cross-compiles with MXE, which is an older alternative to MSYS2/Docker/modern cross-platform build tools. Script not shared unfortunately. Probably not worth pursuing MXE https://github.com/hpjansson/chafa/issues/72#issuecomment-1173105630

The build script for chafa.py looks suspiciously easy: https://github.com/GuardKenzie/chafa.py/blob/main/.github/workflows/build_wheels.yml

[hpjansson]

My build script is crufty and terrible, and would likely just cause more confusion if I pasted it verbatim. Here's how it works, though:

• The container is vanilla Debian 9 (stretch). Unless you want to support very old distros, you should use something newer.
• It uses the system gcc/glibc.
• I build glib and its deps in the following order: m4 autoconf automake libtool pkg-config libffi zlib expat libxml itstool fribidi gtk-doc glib

Each package is configured with the following:

export PKG_CONFIG_SYSROOT_DIR=${PWD}/install
./configure --enable-static=yes --enable-shared=no --host=x86_64-unknown-linux-gnu --cache-file=${PWD}/temp/config.cache --with-sysroot=${PWD}/install --sysconfdir=/etc

Some of the packages need extra args to ./configure:

• pkg-config: --with-internal-glib --with-libiconv=no
• zlib: --static
• gtk-doc: --disable-scrollkeeper
• glib: --disable-fam --disable-selinux --with-libiconv=no --disable-dtrace --with-pcre=internal --disable-compile-warnings

I try to use the latest versions of everything, but sometimes it's hard to get it to build with old glibc. This set is known to work:

autoconf-2.69.tar.gz
automake-1.12.6.tar.gz
expat-2.5.0.tar.xz
fribidi-v1.0.12.tar.xz
glib-2.48.2.tar.xz
gtk-doc-1.18.tar.gz
itstool-2.0.7.tar.xz
libffi-3.0.11.tar.gz
libtool-2.4.2.tar.gz
libxml2-2.11.1.tar.xz
m4-1.4.18.tar.xz
pkg-config-0.28.tar.gz
zlib-1.2.6.tar.gz

There's more fine print, but if you want to go this route, the above should get you started. Caveat emptor: I came up with this over a decade ago, and it's tuned to keep the static binaries running with decade-old runtimes. There may be better/simpler ways of doing it today.

Feel free to ask if you're running into trouble, I'll answer as time allows.