4 ms·

Actual static binaries (so including libc) should run just fine anywhere, right? The Linux kernel has always had a very stable ABI.

flohofwoe 1y ago
Yes but that limits you to command line applications. GL and X11 (and I assume Wayland) are always linked dynamically. Granted, those don't suffer from glibc's "DLL version hell", but not sure what happens when you link the main executable statically against musl and then load DLLs which dynamically link glibc. Another option is to dynamically link against an old glibc version, the Zig toolchain makes that easy also for C/C++ projects.
- electroly 1y ago
  If you statically link musl, dlopen doesn't work at all. You can't load any shared library.
- badsectoracula 1y ago
  glibc doesn't suffer from DLL version hell as long as you are not doing anything stupid (like using private symbols). If you commit to using just the "C library" bits you can compile a binary linked against glibc on a distro from 1998 and it will work on modern distros just fine. There are many issues with libraries breaking backwards compatibility on Linux (like pretty much all GUI ones) but glibc, X11, OpenGL (and to some extent SDL - it used to not be like that, but in recent years they made "SDL1->SDL2" wrappers and there is or will be a "SDL2->SDL3" wrapper too) are fine. I'm not sure about Vulkan but i'd guess that is fine too.
  - flohofwoe 1y ago
    Last I tried the problem was linking against glibc on a new Linux distro and then attempting to run that executable on an old Linux distro which doesn't have a recent-enough glibc installed (usually Debian with their software stack from the last century). There's probably an obscure linker trick to force an older glibc version number, but if that's the case it really should be the default since the C stdlib is supposed to be ABI backward compatible anyway.
    - palata 1y ago
      Well the "trick" is to build with the oldest glibc version you want to support. Nothing more.
    - badsectoracula 1y ago
      This isn't just a glibc thing but something you can find with any shared library on Linux. For example if you are using a rolling distro and make a build that links against Qt6, the produced binary may not work in another distro that has a slightly older Qt6. As palata mentioned the "trick" is to build using the oldest version you plan to target. You can use a Docker image with, say, Debian (which has official docker images going back to Squeeze released in 2011) to build the binary and release that. AFAIK there are some tools that allow you to fudge symbols, etc to allow you to use whatever you have on your system but these feel like brittle solutions and the easiest one is to just build on an older/stable release. It isn't like it takes more than a second to make a VM or docker image anyway :-P.
    - gpderetta 1y ago
      It can't be the default, otherwise using any new feature would fail.
      - flohofwoe 1y ago
        When did glibc last introduce a new ABI-breaking feature that's commonly used by applications though?
        gpderetta 1y ago
        The recent-ish change to 64 bit time_t was a fairly big one. It shouldn't affect 64 bit targets though.
  - p_l 1y ago
    glibc very much suffers from version hell, because: a) glibc will drop older versioned symbols over time making your binary not work at all b) glibc owns ld.so and is not afraid to make incompatible changes, which is why running Sid Meyer's Alpha Centauri linux port requires that you dig out not just libc, but the entire dynamic linking stack and know how to bypass default executable interpreter in ELF files.
    - pmarreck 1y ago
      ...aaaaand stuff like this is exactly why NixOS is the only sensible Linux distro
      - vanviegen 1y ago
        NixOS removes outdated packages from its repo pretty rapidly... :-/
maxlin 1y ago
Not true even for all apps having just libc. I wanted to port my semi-minimal 3D ECS game engine ~(10k lines) to a minimal distro, so I decided on Alpine after figuring Arch is actually very bloated on comparison. I had to recompile even the single-executable command line prebuild system (premake5) for musl. Musl is a more minimal version of libc. Got it to work fine after that, building a few components from source and getting a few like sdl from the distribution's repos. (also had to of course install relevant driver bits to get opengl working as the distro is truly minimal)

flohofwoe 1y ago

Yes but that limits you to command line applications. GL and X11 (and I assume Wayland) are always linked dynamically. Granted, those don't suffer from glibc's "DLL version hell", but not sure what happens when you link the main executable statically against musl and then load DLLs which dynamically link glibc. Another option is to dynamically link against an old glibc version, the Zig toolchain makes that easy also for C/C++ projects.

electroly 1y ago
If you statically link musl, dlopen doesn't work at all. You can't load any shared library.
badsectoracula 1y ago
glibc doesn't suffer from DLL version hell as long as you are not doing anything stupid (like using private symbols). If you commit to using just the "C library" bits you can compile a binary linked against glibc on a distro from 1998 and it will work on modern distros just fine. There are many issues with libraries breaking backwards compatibility on Linux (like pretty much all GUI ones) but glibc, X11, OpenGL (and to some extent SDL - it used to not be like that, but in recent years they made "SDL1->SDL2" wrappers and there is or will be a "SDL2->SDL3" wrapper too) are fine. I'm not sure about Vulkan but i'd guess that is fine too.
- flohofwoe 1y ago
  Last I tried the problem was linking against glibc on a new Linux distro and then attempting to run that executable on an old Linux distro which doesn't have a recent-enough glibc installed (usually Debian with their software stack from the last century). There's probably an obscure linker trick to force an older glibc version number, but if that's the case it really should be the default since the C stdlib is supposed to be ABI backward compatible anyway.
  - palata 1y ago
    Well the "trick" is to build with the oldest glibc version you want to support. Nothing more.
  - badsectoracula 1y ago
    This isn't just a glibc thing but something you can find with any shared library on Linux. For example if you are using a rolling distro and make a build that links against Qt6, the produced binary may not work in another distro that has a slightly older Qt6. As palata mentioned the "trick" is to build using the oldest version you plan to target. You can use a Docker image with, say, Debian (which has official docker images going back to Squeeze released in 2011) to build the binary and release that. AFAIK there are some tools that allow you to fudge symbols, etc to allow you to use whatever you have on your system but these feel like brittle solutions and the easiest one is to just build on an older/stable release. It isn't like it takes more than a second to make a VM or docker image anyway :-P.
  - gpderetta 1y ago
    It can't be the default, otherwise using any new feature would fail.
    - flohofwoe 1y ago
      When did glibc last introduce a new ABI-breaking feature that's commonly used by applications though?
      - gpderetta 1y ago
        The recent-ish change to 64 bit time_t was a fairly big one. It shouldn't affect 64 bit targets though.
- p_l 1y ago
  glibc very much suffers from version hell, because: a) glibc will drop older versioned symbols over time making your binary not work at all b) glibc owns ld.so and is not afraid to make incompatible changes, which is why running Sid Meyer's Alpha Centauri linux port requires that you dig out not just libc, but the entire dynamic linking stack and know how to bypass default executable interpreter in ELF files.
  - pmarreck 1y ago
    ...aaaaand stuff like this is exactly why NixOS is the only sensible Linux distro
    - vanviegen 1y ago
      NixOS removes outdated packages from its repo pretty rapidly... :-/

maxlin 1y ago

Not true even for all apps having just libc. I wanted to port my semi-minimal 3D ECS game engine ~(10k lines) to a minimal distro, so I decided on Alpine after figuring Arch is actually very bloated on comparison. I had to recompile even the single-executable command line prebuild system (premake5) for musl. Musl is a more minimal version of libc. Got it to work fine after that, building a few components from source and getting a few like sdl from the distribution's repos. (also had to of course install relevant driver bits to get opengl working as the distro is truly minimal)