The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

One-file Linux app dream sparks cheers, groans, and memes

TLDR: The dev is building a single Linux app that runs on any distro by patching Go and faking the library loader in musl. Comments split: some crave a universal package, others slam it as pro‑proprietary and argue shared libraries or containers should win, triggering memes and a lively debate.

A developer just declared a quest for the “Holy Grail”: a single Linux app that runs everywhere, even with fast graphics. He patched Go, added a new build target for the musl flavor of Linux, and wired his Go code straight into the Godot game engine to chase the one-file dream. Then came the plot twist: musl blocks dlopen (the function that loads graphics drivers) in static apps, so he’s trying a clever “detour” hack to roll his own loader. Translation: make one file that just works on any distro. Cue the popcorn, and background.

Commenters brought the heat. amelius begged for a magic tool that grabs all the needed pieces and “just runs everywhere.” Meneth dropped the anti-proprietary hammer: this helps closed software, and they don’t like it. mgaunard roasted the cult of static linking—shared libraries exist for a reason—and dunked on containers as “the worst of both worlds.” Meanwhile, athrowaway3z discovered detour and called it a cool hack, while einpoklum wondered if a single app could span 32-bit and 64-bit worlds. The thread quickly turned into a meme parade: “One binary to rule them all,” “dlopen? more like nope-open,” and “Linux, choose your fighter: glibc vs musl.”

Key Points

  • Static Go binaries run widely on Linux (kernel 3.2+), but graphics require dynamic C libraries that differ between glibc and musl.
  • The author enabled musl support by patching the Go runtime with a build overlay and introducing GOOS=musl in graphics.gd.
  • For musl, the approach shifted from c-shared to linking Go with Godot’s c-archive to produce a single binary due to lack of official musl builds.
  • Distributing both glibc and musl builds is undesirable; the goal is a single static binary that works across libc variants.
  • Musl doesn’t support dlopen in static binaries (TLS incompatibilities), but since dlopen is a weak symbol, a custom replacement (inspired by detour and Cosmopolitan) could enable dynamic loading of graphics backends.

Hottest takes

"Is there a tool that takes an executable, collects all the required .so files and produces either a static executable, or a package that runs everywhere?" — amelius
"That seems mostly useful for proprietary programs. I don't like it." — Meneth
"Even worse is containers, which has the disadvantage of both." — mgaunard
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.