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

131–140 of 215 posts

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

#131

Post by paddim8 »

gethly wrote: post #106
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.

Isn't the sole reason why linux sucks(sucked?) for games and other software exactly that there is a gazillion of different libraries with different versions, so you have zero assumptions about the state of the OS, which makes making sw for it such a pain?

Yes. Premature optimisation when it comes to dynamic linking is the reason for why the year of the Linux desktop is far away in my opinion

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

#132

Post by a022311 »

saghm wrote: post #114
a022311 wrote: post #77

Earlier quoted context omitted.

It should be noted that AppImages tend to be noticeably slower at runtime than other packaging methods and also very big for typical systems which include most libraries. They're good as a "compile once, run everywhere" approach but you're really accommodating edge cases here. A "works in most cases" build should also be available for that that it would benefit. And if you can, why not provide specialized packages fo…

IMO one of the best features of AppImage is that it makes it easy to extract without needing external tools. It's usually pretty easy for me to look at an AppImage and write a PKGBUILD to make a native Arch package; the format already encodes what things need to be installed where, so it's only a question of whether the libraries it contains are the same versions of what I can pull in as dependencies (either from the…

I agree. I've seen quite a few AUR packages built that way and I'm using a few myself too. The end user shouldn't be expected to do this though! :D

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

#134

Post by paddim8 »

seba_dos1 wrote: post #18
Meneth wrote: post #9

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

Yeah, in my 20 years of using and developing on GNU/Linux the only binary compatibility issues I experienced that I can think of now were related to either Adobe Flash, Adobe Reader or games. Adobe stuff is of the kind that you'd prefer to not exist at all rather than have it fixed (and today you largely can pretend that it never existed already), and the situation for games has been pretty much fixed by Steam runtim…

Probably because your distro purposefully keeps software out of date because it is too fragile otherwise. I don't think that is reasonable at all for desktop use.

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

#135

Post by oguz-ismail2 »

yjftsjthsd-h wrote: post #129
oguz-ismail2 wrote: post #111

Earlier quoted context omitted.

On some distros, yes. On others it'll fire up Wine for whatever reason

Okay, yes, if you configure binfmt_misc for WINE and not APE then PE-compatible binaries will get run with WINE and not APE. That feels unfair.

>if you configure binfmt_misc for WINE

It came preconfigured on Ubuntu 20.04 and 22.04, don't know about newer versions.

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

#136

Post by fc417fc802 »

toast0 wrote: post #126
mdavid626 wrote: post #121

Earlier quoted context omitted.

You can include it, but - either you use chroot, proot or similar to make /lib path contain your executable’s loader - or you hardcode different loader path into your executable Both are difficult for an end user.

This isn't that hard (that's not to say this is easy, it is tricky). Your executable should be a statically linked stub loader with an awful lot of data, the stub loader dynamically links your real executable (and libraries, including libc) from the data and runs it.

To add to this, in case of any remaining confusion. You can implement your own execve in userspace. [0] But the kernel's execve is a piece of machinery that invokes the loader so obviously it follows that you're free to make any changes you'd like to the overall process.

Bonus points if you add compression or encryption and manage to trip a virus scanner or three. [1]

[0] https://grugq.github.io/docs/ul_exec.txt

[1] https://blackhat.com/presentations/bh-usa-07/Yason/Whitepape...

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

#137

Post by badsectoracula »

a022311 wrote: post #77
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…

It should be noted that AppImages tend to be noticeably slower at runtime than other packaging methods and also very big for typical systems which include most libraries. They're good as a "compile once, run everywhere" approach but you're really accommodating edge cases here. A "works in most cases" build should also be available for that that it would benefit. And if you can, why not provide specialized packages fo…

> It should be noted that AppImages tend to be noticeably slower at runtime than other packaging methods

'Noticeably slower' at what? I've run, e.g. xemu (original xbox emulator) as both manually built from source and via AppImage-based released and i never noticed any difference in performance. Same with other AppImage-based apps i've been using.

Do you refer to launching the app or something like that? TBH i cannot think of any other way an AppImage would be "slower".

Also from my experience, applications released using AppImages has been the most consistent by far at "just working" on my distro.

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

#138

Post by rlpb »

paddim8 wrote: post #130
rlpb wrote: post #95

Earlier quoted context omitted.

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?

Then you update those dependencies. Not very difficult with a package manager. And most dependencies aren't used by a ton of programs in a single system anyway. It is not a big deal in practice.

This would only work if you use dynamic linking. Updating dependencies in a statically built distribution would have no effect.

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

#139

Post by rlpb »

electroly wrote: post #99
rlpb wrote: post #95

Earlier quoted context omitted.

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.

And then how would this be any different in practice from dynamic linking?

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

#140

Post by rlpb »

throwaway2046 wrote: post #109
rlpb wrote: post #95

Earlier quoted context omitted.

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?

Libraries already break their ABI so often that continuously rebuilding/relinking everything is inevitable.

Debian manages perfectly well without.
Post reply on HN