musl

What musl is on Arctic

musl is an opt-in second libc installed at /usr/musl, alongside glibc rather than instead of it. There is no separate musl edition and no separate ISO — the same system can have both, and glibc remains what the base system is built against.

alpm ins musl

Binaries are glibc

Every binary package in the repositories is compiled against glibc. Installing one on a musl-only basis will not work, and alpm says so rather than letting it fail confusingly:

Musl libc can only use source pkgs on Arctic.
Binaries are compiled via glibc.

The way through is to build from source:

alpm ins -s some-package

Package naming

alpm's local database is keyed by package name globally, not per repository, so a musl build of something that already exists takes a -musl suffix — busybox-musl alongside busybox. Packages with no glibc counterpart keep their plain name.

The musl repository holds them.

Building musl packages

build/arctic-musl-sandbox --check
build/arctic-musl-sandbox build/build-batch.sh some-package

This is the musl counterpart of arctic-sandbox: the same read-only host, plus a real musl toolchain at /usr/musl inside the sandbox with CC and MUSLGCC already pointing at it.

It injects those paths with read-only overlays rather than a writable tmpfs, so /usr/lib stays as read-only as it is under the ordinary sandbox — a recipe that forgets DESTDIR still fails closed.

Two gotchas worth knowing

Both of these were found the hard way and will bite anyone porting something to musl:

Exported CC is not always enough. A Makefile with its own CC = gcc wins over the environment. It has to go on the command line:

make CC="$MUSLGCC"

-static often fails. musl folds crypt(), libm and librt into libc itself, so there are no separate -lcrypt -lm -lrt archives to find. A build that probes for them unconditionally fails under -static and works dynamically.

Honest status

musl on Arctic is real but young: musl itself and busybox-musl build and package correctly, and the sandbox for building more is in place. It is not a complete parallel system, and depend= in a recipe is metadata — the build host is not staged with a recipe's declared dependencies automatically, so a musl port needing one currently stages it by hand.

More: arctic linux docs · install · declarative configuration · generations and rollback · init systems · kernels · packages (alpm) · desktops and audio · ephemeral shells · building from source