SoLo: Load glibc GPU drivers from a fully static musl binary
Solo – a .so loader for static Linux binaries
SoLo is a .so loader for static Linux binaries that lets a musl-linked executable dlopen() the host's glibc-built Vulkan and OpenGL drivers. It includes its own ELF loader for x86-64 and aarch64, a glibc ABI bridge over musl, and a demo that runs a compute shader through the system's unmodified Vulkan driver. CI loads over 2,100 shared objects from the 1,000 most-installed Debian packages.
Shipping a distro because you need one system .so is not portability.
- comex
This is a big forwards-compatibility risk. Suppose glibc adds a new symbol, and then a GPU driver adds a dependency on that symbol. The user wants to run an old executable with the updated GPU driver (maybe the old GPU driver doesn’t support their GPU). Normally, this would work fine: the user has to use a new copy of glibc, which will be compatible with both the new GPU driver and the old executable. But with your approach, the GPU driver is forced to use the glibc reimplementation which has been statically linked into the executable. Which, since the executable is old, can’t possibly implement the new symbol.
The same issue would occur if glibc adds a new version of an existing symbol and then the GPU driver is recompiled. (Or, for that matter, if a GPU driver adds a dependency on a symbol which glibc has always supported but which isn’t in the subset that you reimplemented, though in theory that could be solved if you reimplemented 100% of the symbols.)
- eqvinox
If you can figure out your own ELF loader, you can figure out how to build a partially static executable that doesn't need this. You can mix static and dynamic linking. Build tooling around that is just shit.
- nomel
I don't know much about musl.
> GPU: Vulkan and OpenGL drivers are supplied by the host as shared objects, usually built against glibc, and a fully static musl binary cannot normally dlopen() them.
Why? Have people managed to break the ancient concept of shared libraries, and this is a fix for that?
- pg83
How this differs (is better!) from prior art - https://github.com/pg83/solo#how-this-differs-from-prior-wor...
- socceroos
Do people say "so", "ess-oh" or "dot-ess-oh"? The title "a .so" is clunky to the "ess-oh" gang.
- setheron
If you dynamically sold an SO are you still static even if you did it "custom" ?
At that point it's a dynamic loader in another name?
- simonask
It is a testament to the complete failure of the GNU/Linux userland that something like this seems at all attractive to spend time on (or, it seems, LLM tokens).
Actually, scratch that, because Windows and macOS have historically struggled with ABI compatibility as well (macOS less so, due to not caring about backward compatibility in the first place).
How did we get to the point where people feel they need to go to the length of embedding an ELF loader in their binary (!!) rather than just linking with glibc?
- catlifeonmars
So not completely static, since it must link against a libc :P