For non-graphical apps, you can link statically against musl to produce a binary that only depends on the Linux kernel version and not the version or type of libc on the system. You may take a performance hit as musl isn't optimized for speed, and a size hit for shipping your own libc, and a feature hit because musl is designed to be minimal, but for many command line tools all of these downsides are acceptable.
reply.interp to a glibc/libc you ship or static linking. These days it’s probably faster (in dev time) to just run a container than setting up a bespoke interp and a parallel set of libraries (and the associated toolchain changes or binary patching needed to support it).
replyRunning a container is exactly my current solution as well.
replyAre there any other solutions that don't depend on glibc?
Guix (and I assume Nix as well, but I only know Guix) can create a package that is completely self contained including glibc. You can even have it be an AppImage
https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix...
replyGlibc is half of GNU/Linux. You can of course use another libc, but it will be a different OS.
replyYeah, even library loading relies on glibc, so we can't really escape glibc on GNU/Linux.
replyI don't really know why people expect to be able to bypass the OS and not have problems. It seems to come from people who think a "Linux OS" only consists of the Linux kernel.
replyI wonder if anyone implemented loading shared libraries without glibc? It shouldn't be that hard, just need to implement ELF parser and glibc-compatible relocation mechanism.
replyI don't think nobody has done, that. It is just that vendoring your own OS comes with a lot of work.
reply