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

91–100 of 215 posts

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

#91

Post by ValdikSS »

`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

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

#92

Post by ValdikSS »

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?

AppImage is not what you need. It's just an executable wrapper for the archive. To make the software cross-distro, you need to compile it manually on an old distro with old glibc, make sure all the dependencies are there, and so on.

https://docs.appimage.org/reference/best-practices.html#bina...

There are several automation tools to make AppImages, but they won't magically allow you to compile on the latest Fedora and expect your executable to work on Debian Stable. It's still require quite a lot of manual labor.

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

#93

Post by pjmlp »

account42 wrote: post #75
pjmlp wrote: post #66

Earlier quoted context omitted.

Think of any program that uses dynamic libraries as extension mechanism, and now replace it with standard UNIX processes, each using any form of UNIX IPC to talk with the host process instead.

In theory there might be a different RAM usage with the two approaches. In practice there is not.

And your measurements are available where?

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

#94

Post by ValdikSS »

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?

>I wonder though, if I package say a .so file from nVidia, is that allowed by the license?

It won't work: drivers usually require exact (or more-or-less the same) kernel module version. That's why you need to explicitly exclude graphics libraries from being packaged into AppImage. This make it non-runnable on musl if you're trying to run it on glibc.

https://github.com/Zaraka/pkg2appimage/blob/master/excludeli...

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

#95

Post by rlpb »

arghwhat wrote: post #47
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.

Dynamic libraries have been frowned upon since their inception as being a terrible solution to a non-existent problem, generally amplifying binary sizes and harming performance. Some fun quotes of quite notable characters on the matter here: https://harmful.cat-v.org/software/dynamic-linking/ In practice, a statically linked system is often smaller than a meticulously dynamically linked one - while there are many cop…

Imagine a fully statically linked version of Debian. What happens when there’s a security update in a commonly used library? Am I supposed to redownload a rebuild of basically the entire distro every time this happens, or else what?

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

#96

Post by ValdikSS »

lizknope wrote: post #58
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?

15-30 years ago I managed a lot of commercial chip design EDA software that ran on Solaris and Linux. We had wrapper shell scripts for so many programs that used LD_LIBRARY_PATH and LD_PRELOAD to point to the specific versions of various libraries that each program needed. I used "ldd" which prints out the shared libraries a program uses.

It you know what you're doing and scrupulous enough, you can package the software in a way that it works 25 years later.

https://xcancel.com/ValdikSS/status/1843044963443253678

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

#97

Post by surajrmal »

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)

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

#98

Post by zoobab »

netbioserror wrote: post #81

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.

I have an idea for a static linux distribution based on musl, with either an Alpine rebuild or Gentoo-musl:

http://stalinux.wikidot.com

The documentation to make static binary with GLibc is sparce for a reason, they don't like static binaries.

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

#99

Post by electroly »

rlpb wrote: post #95
arghwhat wrote: post #47

Earlier quoted context omitted.

Dynamic libraries have been frowned upon since their inception as being a terrible solution to a non-existent problem, generally amplifying binary sizes and harming performance. Some fun quotes of quite notable characters on the matter here: https://harmful.cat-v.org/software/dynamic-linking/ In practice, a statically linked system is often smaller than a meticulously dynamically linked one - while there are many cop…

Imagine a fully statically linked version of Debian. What happens when there’s a security update in a commonly used library? Am I supposed to redownload a rebuild of basically the entire distro every time this happens, or else what?

Steel-manning the idea, perhaps they would ship object files (.o/.a) and the apt-get equivalent would link the system? I believe this arrangement was common in the days before dynamic linking. You don't have to redownload everything, but you do have to relink everything.

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

#100

Post by abigail95 »

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.

Why would I want to be constantly calling into code I have no control over, that may or may not exist, that may or may not be tampered with.

I lose control of the execution state. I have to follow the calling conventions which let my flags get clobbered.

To forego all of the above including link time optimization for the benefit of what exactly?

Imagine developing a C program where every object file produced during compilation was dynamically linked. It's obvious why that is a stupid idea - why does it become less stupid when dealing with a separate library?

Post reply on HN