Solo – a .so loader for static Linux binaries

Original Article ↗ Hacker News Discussion ↗

A new project, Solo, embeds its own ELF loader into statically linked Linux binaries so they can `dlopen()` host GPU and other glibc‑only drivers even when built against musl. Commenters weigh the appeal of portable, mostly‑static binaries against the risks of re‑implementing parts of glibc’s ABI and loader semantics, warning about forward‑compatibility, security, and the fragility of undocumented behavior. The thread broadens into a critique of Linux’s fragmented user‑space ABI and packaging story, contrasting containers, AppImage, and “build against an old glibc” strategies with more radical ideas like freestanding, libc‑free userland.

Project purpose and approach

  • Solo aims to let fully static musl-linked Linux binaries dynamically load host-provided .so drivers (notably GPU drivers built against glibc) by embedding:
    • A custom ELF loader (x86‑64, aarch64).
    • A “glibc ABI bridge” that shims glibc symbols on top of musl.
  • The goal is portable binaries that run unmodified on glibc distros, musl distros (e.g. Alpine), and eventually Android/bionic, while still feeling “static” from the app’s perspective.

Security and correctness concerns

  • Several comments warn that implementing a custom ELF loader and ABI shim is fragile:
    • Any bug in mapping and executing code is a potential RCE vector, especially if used in privileged contexts.
    • SysV/ELF ABI has undocumented subtleties (e.g., AT_SECURE) that are easy to get wrong.
  • The author responds that:
    • ld.so already does similar mapping.
    • The project has extensive tests, 100% coverage, and is run against ~1000 Debian packages, with plans for fuzzing.

glibc, musl, and ABI entanglement

  • Long discussion that on Linux:
    • ld.so, libc.so, libstdc++, TLS, atomics, unwinding, and C++ globals are deeply intertwined and partly undocumented.
    • Shared libraries compiled for glibc effectively depend on that exact glibc plus its loader.
  • Some argue this design makes alternative libcs (musl, bionic) second‑class and forces hacks like Solo.
  • Others counter that for C, the ABI is largely stable and glibc generally maintains backward compatibility, especially if you build against an older glibc.

Static vs dynamic linking and distribution

  • Pro‑static camp:
    • Wants fully self-contained binaries, distrusts glibc and distro churn, and likes freestanding C/Rust or direct syscalls.
    • Notes pain with proprietary/glibc‑only GPU drivers, NSS, Mesa, etc. on musl systems.
  • Skeptical camp:
    • Argues Solo introduces forward‑compatibility risks: future drivers might require new or versioned glibc symbols the embedded shim doesn’t support.
    • Suggests simpler approaches: dynamically link against an old glibc, use containers (Docker/Flatpak), or AppImage/manylinux‑style baselines.

Is this a niche problem?

  • Some say this only matters for musl‑based distros or proprietary drivers; most distros are fine with standard dynamic linking.
  • Others insist it’s a real pain for small independent developers who can’t build/package per‑distro yet want single binaries that “just work” across glibc, musl, and Android.

LLM‑generated code and documentation

  • The author openly uses LLMs for code and docs and defends this as high‑productivity, with human review.
  • Some readers strongly distrust LLM‑authored READMEs, perceiving them as “slop” and associating them with low‑effort projects.
  • Others argue style prejudice is misplaced and that technical quality and tests matter more than whether text “sounds like” an LLM.