Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

github.com

Post reply on HN
Print view View original

31–40 of 215 posts

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#31

Post by VadimPR »

gilli wrote: post #29
TheDong wrote: post #11

Earlier quoted context omitted.

There are things like this. The things I know of and can think of off the top of my head are: 1. appimage https://appimage.org/ 2. nix-bundle https://github.com/nix-community/nix-bundle 3. guix via guix pack 4. A small collection of random small projects hardly anyone uses for docker to do this (i.e. https://github.com/NilsIrl/dockerc ) 5. A docker image (a package that runs everywhere, assuming a docker runtime is a…

I wish AppImage was slightly more user friendly and did not require the user to specifically make it executable.

We fix this issue by distributing ours in a tar file with the executable bit set. Linux novices can just double click on the tar to exact it and double click again on the actual appimage.

Been doing it this way for years now, so it's well battle tested.

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#32

Post by mdavid626 »

amelius wrote: post #20
TheDong wrote: post #11

Earlier quoted context omitted.

There are things like this. The things I know of and can think of off the top of my head are: 1. appimage https://appimage.org/ 2. nix-bundle https://github.com/nix-community/nix-bundle 3. guix via guix pack 4. A small collection of random small projects hardly anyone uses for docker to do this (i.e. https://github.com/NilsIrl/dockerc ) 5. A docker image (a package that runs everywhere, assuming a docker runtime is a…

AppImage looks like what I need, thanks. I wonder though, if I package say a .so file from nVidia, is that allowed by the license?

Don't forget - AppImage won't work if you package something with glibc, but run on musl/uclibc.

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#33

Post by fieu »

amelius wrote: post #5

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?

Ermine: https://www.magicermine.com/

It works surprisingly well but their pricing is hidden and last time I contacted them as a student it was upwards of $350/year

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#37

Post by [deleted] »

iberator wrote: post #15
einpoklum wrote: post #2

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"?

Yup. Just compile it as static executable. Static binaries are very undervalued imo.

[deleted]

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#38

Post by vv_ »

mgaunard wrote: post #36

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.

It's easier to distribute software fully self-contained, if you ignore the pain of statically linking everything together :)

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#40

Post by breezykoi »

juliangmp wrote: post #34
Meneth wrote: post #9

That seems mostly useful for proprietary programs. I don't like it.

Why? Foss software also benefits from less dependency hell.

For distro-packaged FOSS, binary compatibility isn't really a problem. Distributions like Debian already resolve dependencies by building from source and keeping a coherent set of libraries. Security fixes and updates propagate naturally.

Binary compatibility solutions mostly target cases where rebuilding isn't possible, typically closed source software. Freezing and bundling software dependencies ultimately creates dependency hell rather than avoiding it.

Post reply on HN