- So what we need is essentially a "libc virtualization".
But Musl is only available on Linux, isn't it? Cosmopolitan (https://github.com/jart/cosmopolitan) goes further and is available also on Mac and Windows, and it uses e.g. SIMD and other performance related improvements. Unfortunately, one has to cut through the marketing "magic" to find the main engineering value; stripping away the "polyglot" shell-script hacks and the "Actually Portable Executable" container (which are undoubtedly innovative), the core benefit proposition of Cosmopolitan is indeed a platform-agnostic, statically-linked C standard (plus some Posix) library that performs runtime system call translation, so to say "the Musl we have been waiting for".
- 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?
- Binary comparability extends beyond the vide that runs in your process. These days a lot of functionality occurs by way of IPC which has a variety of wire protocols depending on the interface. For instance there is dbus, Wayland protocols, varlink, etc. Both the wire protocol, and the APIs built on top need to retain backwards comparability to ensure Binary compatibility. Otherwise you're not going to be able to run on various different Linux based platforms arbitrarily. And unlike the kernel, these userspace surfaces do not take backwards compatibility nearly as important. It's also much more difficult to target a subset of these APIs that are available on systems that are only 5 years old. I would argue API endpoints on the web have less risk here (although those break all the time as well)
by tuhgdetzhh
0 subcomment
- The best binary compatibily you can get on Linux is via Wine.
Source: https://blog.hiler.eu/win32-the-only-stable-abi/
by athrowaway3z
1 subcomments
- I'd never heard of detour. That's a pretty cool hack.
- It's funny how people insist on wanting to link everything statically when shared libraries were specifically designed to have a better alternative.
Even worse is containers, which has the disadvantage of both.
- `dlopen`'ing system libraries is an "easy" hack to try to maintain compatibility with wide variety of libraries/ABIs. It's barely used (I know only of SDL, Small HTTP Server, and now Godot).
Without dlopen (with regular dynamic linking), it's much harder to compile for older distros, and I doubt you can easily implement glibc/musl cross-compatibility at all in general.
Take a look what Valve does in a Steam Runtime:
- https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/pressure-vessel.md
- https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/subprojects/libcapsule/doc/Capsules.txt
by dunder_cat
0 subcomment
- Related discussion (the actual project is mentioned in the issue):
"Detour: Dynamic linking on Linux without Libc" https://news.ycombinator.com/item?id=45740241
- Isn't this asking for the exact trouble musl wanted so spare you from by disabling dlopen()?
by einpoklum
5 subcomments
- This seems interesting even regardless of go. Is it realistic to create an executable which would work on very different kinds of Linux distros? e.g. 32-bit and 64-bit? Or maybe some general framework/library for building an arbitrary program at least for "any libc"?
- Do I get this right that this effectively dlopens glibc (indirectly) into an executable that is statically linked to musl? How can the two runtimes coexist? What about malloc/free? AFAIK both libc's allocators take ownership of brk, that can't be good. What about malloc/free across the dynamic library interface? There are certainly libraries that hand out allocated objects and expect the user to free them, but that's probably uncommon in graphics.
- I managed to get this combo going not too long ago with my musl rust app but I found that even after it all was compiled and loading the lib it did not function properly because the library I loaded still depended on libc functions. even with everything compiled into a huge monolithic musl binary it couldn't find something graphics related
I eventually decided to keep the tiny musl app and make a companion app in a secondary process as needed (since the entire point of me compiling musl was cross platform linux compatibility/stability)
by netbioserror
2 subcomments
- I've been statically linking Nim binaries with musl. It's fantastic. Relatively easy to set up (just a few compiler flags and the musl toolchain), and I get an optimized binary that is indistinguishable from any other static C Linux binary. It runs on any machine we throw it at. For a newer-generation systems language, that is a massive selling point.
- you'll likely be interested in [1] and [2] for further reading
[1]: https://github.com/ziglang/zig/issues/7240
[2]: https://www.youtube.com/watch?v=pq1XqP4-qOo
- That seems mostly useful for proprietary programs. I don't like it.
- If you're using dlopen(), you're just reimplementing the dynamic linker.
Hacker News