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.
.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).
Running a container is exactly my current solution as well.
Are there any other solutions that don't depend on glibc?
Glibc is half of GNU/Linux. You can of course use another libc, but it will be a different OS.
Yeah, even library loading relies on glibc, so we can't really escape glibc on GNU/Linux.
I 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.
I don't think nobody has done, that. It is just that vendoring your own OS comes with a lot of work.
I 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.