@sheevink@dotstdy@Gankra it could, but then that library would want other libraries loaded, but those don't exist on disk because it's statically compiled in, and we can't just point to that because it gets optimized (inlining and unused are removed)
you could have a dynamic library embedded essentially, but you're loosing out on all the benefits of static linking, and get the worst of both worlds
@psykose@tthbaltazar@sheevink@dotstdy@Gankra Isn't OpenGL (maybe not libGL.so.1 and other GLX stuff though, consider libOpenGL.so.0) supposed to have an ABI defined in an independent manner of the libc though?
@lanodan not really no, the issue is having a `NEEDED libc.so` at all. you can't really have a process that loads another one that then depends on libc.so (libGL and loading the graphics stack then also depends on like another 20 libraries and for some drivers even libLLVM, etc, just for posterity). the only way to have 'portably loaded .so plugins' that you can open anywhere from any executable (whether static or dynamic against glibc/musl/whatever) is when they don't depend on libc, and every random library people distribute would have the dependency
https://www.openwall.com/lists/musl/2022/01/18/5 is somewhat analogous, but there's probably even more stuff that doesn't work on top of this, and aside from the thought experiment all anyone can really do is say "it doesn't work, don't even try it"
@lanodan if someone really cared about golfing this to 'prove me wrong' they might have some luck with a freestanding linux binary (no libc) that loads everything, but dunno, that seems quite painful
it's also more painful than just distributing an electron program :^)