3 ms·

I'm sick of glibc compatibility problems. Are there any recommended replacements?

emidln 1y ago
.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).
- liqilin1567 1y ago
  Running a container is exactly my current solution as well. Are there any other solutions that don't depend on glibc?
  - retatop 1y ago
    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-pack.html https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix...
1718627440 1y ago
Glibc is half of GNU/Linux. You can of course use another libc, but it will be a different OS.
- liqilin1567 11mo ago
  Yeah, even library loading relies on glibc, so we can't really escape glibc on GNU/Linux.
  - vbezhenar 11mo ago
    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.
    - 1718627440 11mo ago
      I don't think nobody has done, that. It is just that vendoring your own OS comes with a lot of work.
  - 1718627440 11mo ago
    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.
electroly 11mo ago
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).

liqilin1567 1y ago
Running a container is exactly my current solution as well. Are there any other solutions that don't depend on glibc?
- retatop 1y ago
  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-pack.html https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix...

1718627440 1y ago

Glibc is half of GNU/Linux. You can of course use another libc, but it will be a different OS.

liqilin1567 11mo ago
Yeah, even library loading relies on glibc, so we can't really escape glibc on GNU/Linux.
- vbezhenar 11mo ago
  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.
  - 1718627440 11mo ago
    I don't think nobody has done, that. It is just that vendoring your own OS comes with a lot of work.
- 1718627440 11mo ago
  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.

electroly 11mo ago

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.