The state of binary compatibility on Linux and how to address it

Original Article ↗ Hacker News Discussion ↗

glibc ABI and toolchain strategies

  • Several commenters note the article omits the “right way” to target older glibc: using linker VERSION scripts (binutils ld support) to pin symbol versions, including glibc internals, so binaries built on new distros run on older ones.
  • Others point out the importance of -static-libgcc and -static-libstdc++ for C++ compatibility; missing those has bitten projects (including games) for years.
  • A recurring complaint is that standard Linux toolchains implicitly target the host’s glibc, making it hard to cross‑compile to older ABIs. Zig’s toolchain is praised for solving this (via glibc ABI metadata and sysroots) and making “target glibc X.Y” trivial.

Static vs dynamic linking, and why libc is special

  • Many participants argue “just statically link” is not a general solution:
    • glibc’s NSS and PAM stacks rely heavily on dynamic loading.
    • GPU stacks (OpenGL/Vulkan drivers) and some plugins are only provided as shared objects.
    • Mixing static linking with dlopen is described as fragile, especially when multiple libcs or allocators are involved.
  • Others counter that dynamic linking has its own long‑term maintenance issues and suggest stricter backwards‑compatibility guarantees or “base” APIs that never break.

Fragmentation, distros, and packaging

  • Multiple comments stress that Linux ≠ one OS; each distro (and even each major release) is effectively its own platform, with no shared ABI authority.
  • The practical advice: target a small set of enterprise/LTS distros; expect to rebuild per major version; or ship source and let distro maintainers/package managers integrate it.
  • Python’s manylinux effort is cited as an example of how hard it is to depend on anything beyond glibc/libstdc++ without bundling.

How good/bad is glibc really?

  • Some argue glibc maintains old symbols extremely well and that the real problem is running new glibc‑built binaries on old systems, not vice versa.
  • The proposal in the article to split glibc into separate loader/libc/threading libraries is criticized as not actually fixing the cited regressions and being technically entangled (TLS, syscalls, loader interactions).
  • Others say glibc’s tight coupling with the dynamic loader prevents shipping multiple libc versions side‑by‑side and thus is a major distribution pain point.

Alternatives and workarounds

  • Mentioned approaches include: polyfill‑glibc shims, Go binaries built with CGO_ENABLED=0, Nix/NixOS style isolation, containers, Wine/Win32 as the “only stable ABI,” and niche tools like Rugix or Cosmopolitan (with skepticism about malware flagging).