Has anybody been able to build a statically linked binary that shows a Vulkan surface? I’ve put some context around this problem in the video. I understand that the vulkan driver has to be loaded dynamically - so it’s more of a question whether a statically built app can reliably load and talk with it. I think it should be possible but haven’t actually seen anyone make it work. I’m aware of “static-window9” by Andrew Kelley but sadly it doesn’t work any more (at least on my Gentoo machine T_T).
(I’m also aware of AppImages but I don’t think they’re the “proper” solution to this problem - more like a temporary bandaid - better than Docker but still far from perfect)
The question should by why you’d want to. Careful if your reply is something about ‘one binary to work on a very diverse arrangement of library pinnings’ because the next question would be ‘why would you think that’s either achievable or valuable as a goal’; and toss in a ‘why try to ship the same binary in several different repos anyway’ bonus question.
In short, if your biggest problem is how to build a binary that works everywhere, you have a lot of questions about responsible build/release processes to answer, and they will be embarrassing for you.
Because the application working is more important than the downsides in my case. Its quite useful for an application which hasn’t been updated in a long time, will never receive updates again, or doesn’t work in my nonstandard environment.
I have had older applications fail to function due to DLL hell.
I think of demoscene, game jams, desktop pets and other sorts of small home-brew software written by & for small groups of people. There is nothing embarrassing about one-off programs. I understand that what you said is just a figure of speech and you don’t really think so (and thank you for a well thought comment) but it still makes me kind of sad to see this kind of shaming. It’s discouraging people from being creative.
I’d say my bar is already low. A toy GUI program that draws a triangle and plays a sound should work on my friend’s machine (with a different set of system libraries) and it shouldn’t randomly break when OS update bumps some library version. AFAIK something like that would require a static binary (INTERP is a no-go) and an ability to dlopen stuff at runtime.
Writing software that “just works” shouldn’t be as hard as it is.
Sounds like flatpaks/appimages with extra steps
Includes all dependencies? ✔️
A single file? ✔️
Independent of host libraries? ✔️
Limited learning curve? ✔️
Not sure how appimages handle it internally, but with flatpaks you can even be storage efficient with layers, whereas 100s of static binaries could contain an awful lot of duplicates.
I’m fairly sure the complexity of flatpak/appimage solutions are far more than the static linking of a binary (at least on non-glibc systems). Its often a single flag (Ex:
-static) that builds the DLLs into the binary, not a whole container and namespace.So?
Using the right build platform you could design a single flag to enable automatic appimage building as well.
Just seems like a cleaner build environment to me, exactly what you’d want to gaurentee things remain distro agnostic