Solo: a .so loader for static Linux binaries
17 points by linkdd
17 points by linkdd
Turns out there's a fun category of software that people really don't want to touch manually, but do want to create - loaders. I've seen at least 4 published over a couple of months and I've got 2 of my own. Having dealt with those formats and relocations in the past... I get why.
Absolutely. This idea came to me around 2021, when I was just starting to work on my statically linked Linux, and I really wanted to run Nvidia drivers on it. But I roughly estimated that it would take about six man-months of work just to get a tech demo, and I gave up. LLMs made some impossible things possible, and that's awesome :))
Loading static pie elfs is quite straight forward. I do this for freestanding elfs that run on any OS.
By the way, I disagree with the "vibecoding" label! Vibecoding is a process that generates tons of AI slop that no one has reviewed, designed, or is responsible for. My production process is completely different – I go through a bunch of different design options, explore different implementations, and delve deeply into what's going on. I personally call it "clauding," but I don't force that name on anyone :))
There is no clauding tag. The vibecoding tag applies to all projects using mainly LLM generated code.
and delve deeply into what's going on
I’m glad in-person meetups exist: our group can test this assertion. If you live in one of the Handmade Cities, I encourage you to attend the next one! (Sometimes we let presenters remote in too, just shoot us an email.)
speaking of "clauding" -- honest question, was the readme written/revised by claude?
Yes, of course.
I wrote the skeleton in my native language, then Claude translated it, and there were several iterations of adding to it.
My English is terrible, and even this message was translated using Google Translate.
Yes, of course.
I would have liked to see it mentioned upfront that the readme was written with an LLM.
I wrote the skeleton in my native language, then Claude translated it, and there were several iterations of adding to it.
Unfortunately, claude didn't just translate it, it claude-ified it. The resulting style is an instant turn-off for me and probably others who have read too much LLM-generated prose, and don't want to read any more. Using a purpose-specific machine translation system like Google Translate to translate the readme from Russian (I am assuming) would have likely produced a much better result. Also, I would recommend including the original version of a readme or any similar document that you translated with machine translation. That way those who speak that language could read the original (as I probably could have), instead of only having the (often lower quality) output of an LLM, and others could use a translation tool of their choice.
My English is terrible, and even this message was translated using Google Translate.
got it. maybe lobsters can start allowing comments in languages other than English the way some other technical communities have, but that's a larger discussion.
Its neat hack done countless times, but unless userland gpu vendors and libc make this actually supported approach, its gonna not be reliable in the long run.
I think only time will tell.
As an argument, I can cite the fact that I conducted an experiment loading the main Mesa/Nvidia drivers for a couple of years from the Debian archives, and they loaded correctly.
Oh, and I'll also note that you're most likely referring to the detour/cosmo hack. I did something completely different, and as far as I know, no one has done this before - https://github.com/pg83/solo#how-this-differs-from-prior-work
I dont think i've seen libc compat layer before bundled with a dlopen impl (well at least apart from my android/bionic compatibility layer). The approach is mentioned in this prior work https://github.com/pfalcon/foreign-dlopen
Theres also some interest in zig space for loading gpu drivers: https://ziggit.dev/t/whats-the-state-of-the-art-in-zig-ecosystem-for-wayland-vulkan-without-libc-2/16415 https://github.com/TibboddiT/dyn-loader
well at least apart from my android/bionic compatibility layer
Can I see?
The approach is mentioned in this prior work https://github.com/pfalcon/foreign-dlopen
Maybe I'm nuts, but I see a detour/cosmo method there, and nothing more :(
Can I see?
https://github.com/Cloudef/android2gnulinux Theres people maintaining fork of it here https://gitlab.com/android_translation_layer/bionic_translation
Maybe I'm nuts, but I see a detour/cosmo method there, and nothing more :(
Its only talked in the readme but not implemented due to the hairy ABI stability.
Yes, conceptually, this is much more similar to what I've done, compared to what I've seen before! I'll add it to my prior work, thanks.
due to the hairy ABI stability.
May I ask what this is all about? I've been tossing this idea around in my head, and I've been tossing it around with the LLM, and I think I've managed to solve all the problems we could think of, but perhaps I'm missing something?
ABI stability is when lib passes structs to another lib based on contract (the header file, calling convention). If lib is updated and there's a difference in the structure definition that's a ABI breakage. Usually dynamic libraries are designed in way that opaque pointers are passed around instead of structs, but ABI details can still creep in. glibc/musl/bionic all have these issues (errno definition, dirent, stdin/stdout/stderr, etc).