[ShortArrow]

Closes #64.

Why musl

The linux-gnu binaries need the glibc of whichever ubuntu-latest image built them, so the floor rises each time GitHub moves that label. Statically linked musl binaries have no glibc requirement. Building the gnu targets on ubuntu-22.04 would also fix today's floor, but only until that runner image is retired.

The gnu archives keep their names and are still published, because the AUR runex-bin package and the Homebrew tap download them by name.

The portability check

A new CI job builds each musl target natively, on ubuntu-latest and ubuntu-24.04-arm with the toolchain action release.yml uses, and runs runex version in ubuntu:22.04 and debian:12. Any output on stderr fails it, not only a failed start. With the current stable rustc, the x86_64 gnu build no longer fails to start on Ubuntu 22.04: the loader runs it and prints weak version `GLIBC_2.39' not found on every invocation, and the shell hook runs runex on every key press. Against the gnu targets the check failed on both architectures; against musl it passes.

release.yml runs only on a tag, so its two new matrix entries are first exercised by the next release. They build the same targets on the same runners as the check.

Behaviour that differs under musl

When HOME is unset, dirs-sys falls back to getpwuid_r, which musl answers from /etc/passwd only, without NSS. On a host whose users come from LDAP or sssd, runex started without HOME would find no home directory. Interactive shells set HOME.

The latency of runex hook under musl's allocator has not been measured against the gnu build.