solo lets a static musl binary load the host machine's glibc GPU driver

solo is an MIT-licensed project that solves a specific packaging problem: a static Linux executable built against musl cannot load a glibc-linked shared library at runtime, which is exactly what every GPU driver on the machine is. Its README states the goal in one line: "Ship one musl-linked executable. At runtime, load the user's existing glibc-linked GPU driver." The GitHub API returned 597 stars and an MIT licence on 6 September 2026, against a repository created on 14 August, so that is 597 stars in twenty-three days.

Why the wall exists

Static linking is the usual way to make a Linux binary that runs everywhere, because it removes the dependency on whatever libc the target machine carries. The cost is that a static musl binary is then cut off from the host's own shared objects, and drivers cannot be bundled: the Vulkan or CUDA driver has to match the hardware and kernel in front of you. The workarounds are a container, a glibc build per distribution, or an installer.

What it actually contains

Three parts, according to the README. A custom ELF loader that maps segments, resolves symbols and applies relocations. A glibc ABI bridge that translates glibc calls into musl equivalents without loading a second libc into the process. And a dlopen and dlsym style interface on top, so calling code uses the shape it already knows.

The support surface is wider than a proof of concept usually reaches. All four thread-local storage models are handled, including TLSDESC and initial-exec, along with C++ exceptions, symbol versioning and lazy PLT binding. Prebuilt Vulkan binaries exist for x86-64 and aarch64.

The numbers are from CI, and they are specific

The claim worth quoting is the test scope. CI takes the 1,000 most-installed Debian packages, keeps the 885 of them that ship glibc-linked shared objects, and loads about 2,100 objects on both x86-64 and aarch64. Continuous integration runs on Alpine, Fedora and Ubuntu with both GCC and Clang. That is the project's own test suite rather than an independent audit, but it is a stated method with a package set anyone can reproduce, which is a stronger form of claim than a headline compatibility percentage.

The limits are declared rather than discovered. Linux only, on x86-64 and aarch64. The runtime loads once: dlclose returns success but does not unload an image. Initial-exec modules must fit inside a 16 KiB surplus arena, and threads created before a load see zero-initialised storage for those modules, so loading has to happen before you spawn threads. An unimplemented glibc call aborts and prints the symbol it was missing, which is the right behaviour here: a loud failure naming the gap beats a silent wrong answer.

The distribution question this reopens

For anyone shipping a local inference tool, a GPU benchmark, or a desktop application that touches Vulkan, distribution has meant picking a compromise between container images and a per-distro release matrix.

solo moves the risk from "will this run at all" to "will this driver hit an unimplemented glibc call", and the second question is testable in an afternoon against the drivers you care about. The load-once and pre-thread constraints rule out anything that unloads plugins mid-run, so it fits a tool that opens a driver at startup and keeps it.

Twenty-three days is not enough history to know whether the ABI bridge holds against glibc versions the author has never seen. The 885-package test set is the reason to take it seriously anyway.

Source

pg83/solo, GitHub. Star count and licence read from the GitHub API on 6 September 2026.