Ship one musl-linked executable. At runtime, load the user’s existing
glibc-linked GPU driver. No container, no AppImage, and no second libc in the
process.
SoLo crosses that boundary. It provides adlfcn-style source API backed by
its own ELF loader (x86-64 and aarch64) and a glibc ABI bridge implemented on
top of musl.
The result is still one ordinary static executable, but it can use the graphics
driver already installed on the machine.
The repository includes an end-to-end Vulkan proof: a fully static executable
loads the host’s unmodified Vulkan driver, runs a compute shader, and writes
the result to a PNG. Tested on AMD radv, radeonsi, Intel, and NVIDIA GPUs under
Linux, and on Apple M1 under Asahi Linux.
The host keeps the hardware-specific code. You ship everything else.
Grab the prebuilt binary — no clone, no toolchain, any Linux with a Vulkan
driver installed (mesa-vulkan-driversis enough):
vulkan-aarch64is the same demo for arm64 machines. The command discovers
the distro-installed Vulkan ICD in the usual way and produces a 512×512 RGBA
image. This is how we build theShitty release binaries—a blazingly
fast terminal emulator, BTW! To force a particular driver:
ICD manifest names vary slightly between distributions. Passing no–driverlets the embedded Khronos loader perform its normal discovery.
You can verify that the executable itself is not dynamically linked:
Or build the same demo from source, with Python 3 and a C/C++ compiler inPATH:
This is not a toy call tovkCreateInstance. The demo:
The complete example is inbin/vulkan, and the Vulkan program
itself is inmain.cpp.
elf_loader.cppmaps ELF segments, walksDT_NEEDED,
resolves versioned symbols, applies x86-64 relocations, supports ELF TLS and
TLSDESC, materializes IFUNCs, applies RELRO, and runs initializers. Dependencies
that are themselves ELF DSOs are loaded recursively.