I'll also add that I'm aware of glibc's stance on dynamic linking from static binaries. I don't buy the whole NSS argument. It's easily solvable by a basic request/response protocol through some local socket. IMO that argument is just a cheap excuse to justify status quo.

Can't see why you dislike appimages, sure not 100% size efficient - but for one off binaries youre probably not spending much time optimizing anyways.

Not that you couldnt make an appimage 2.0 solving all your issues, but we'd just be back to that package manager xkcd all over again

Rewrite It In Rust ™, and then it'll work everywhere.

joking of course. you still need different builds for glibc and musl

I have no experience with this, but I figured a Rust library might have tried to solve it (static linking is very much the norm here) and I found that ash can statically link the "Vulkan loader". I don't know, what that actually means, for example whether it would still load libxcb at runtime. Might be worth looking into what they do...

See the "Optional linking" section here for their description: https://crates.io/crates/ash#optional-linking