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

201–210 of 215 posts

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

#201

Post by AshamedCaptain »

lmm wrote: post #191
AshamedCaptain wrote: post #154

Earlier quoted context omitted.

What I find amazing is why people continously claim glibc is the problem here. I have a commercial software binary from 1996 that _still works_ to this day. It even links with X11, and works under Xwayland. The trick? It's not statically linked, but dynamically linked. And it doesn't like with anything other than glibc, X11 ... and bdb. At this point I think people just do not know how binary compatibility works at a…

> The trick? It's not statically linked, but dynamically linked. And it doesn't like with anything other than glibc, X11 ... and bdb. How would that work given that glibc has gone through a soname change since then? If it's from 1996 are you sure the secret isn't that it uses non-g libc?

It has libc5 and glibc versions. It even has a version shipped as an rpm, which I guess makes it from 97. The rpm, by the way, also installs.

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

#202

Post by AshamedCaptain »

tonymet wrote: post #183
AshamedCaptain wrote: post #154

Earlier quoted context omitted.

What I find amazing is why people continously claim glibc is the problem here. I have a commercial software binary from 1996 that _still works_ to this day. It even links with X11, and works under Xwayland. The trick? It's not statically linked, but dynamically linked. And it doesn't like with anything other than glibc, X11 ... and bdb. At this point I think people just do not know how binary compatibility works at a…

can you write up a blog of how this is working? because both as a publisher and a user, broken binaries are much more the norm

Broken binaries because of glibc? you'd need to put an example, cause my point is that I'm yet to see any.

If you are talking about _any_ other library, yes, that is a problem. My point is that glibc is the only one who even has a compatibility story.

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

#203

Post by einpoklum »

flohofwoe wrote: post #65
pjmlp wrote: post #27

Earlier quoted context omitted.

We had a time when static binaries where pretty much the only thing we had available. Here is an idea, lets go back to pure UNIX distros using static binaries with OS IPC for any kind of application dynamism, I bet it will work out great, after all it did for several years. Got to put that RAM to use.

The thing with static linking is that it enables aggressive dead code elimination (e.g. DLL are a hard optimization barrier). Even with multiple processes sharing the same DLL I would be surprised if the alternative of those processes only containing the code they actually need would increase RAM usage dramatically, especially since most processes that run in the background on a typical Linux system wouldn't event ev…

> that it enables aggressive dead code elimination

But you still need the compiler of the library objects to place different functions and data items into different sections of your object, e.g.

  gcc -ffunction-sections -fdata-sections
if you want elimination from the executable binary file.

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

#204

Post by tonymet »

AshamedCaptain wrote: post #202
tonymet wrote: post #183

Earlier quoted context omitted.

can you write up a blog of how this is working? because both as a publisher and a user, broken binaries are much more the norm

Broken binaries because of glibc? you'd need to put an example, cause my point is that I'm yet to see any. If you are talking about _any_ other library, yes, that is a problem. My point is that glibc is the only one who even has a compatibility story.

got it thanks for clarifying.

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

#205

Post by lmm »

AshamedCaptain wrote: post #201
lmm wrote: post #191

Earlier quoted context omitted.

> The trick? It's not statically linked, but dynamically linked. And it doesn't like with anything other than glibc, X11 ... and bdb. How would that work given that glibc has gone through a soname change since then? If it's from 1996 are you sure the secret isn't that it uses non-g libc?

It has libc5 and glibc versions. It even has a version shipped as an rpm, which I guess makes it from 97. The rpm, by the way, also installs.

> It has libc5 and glibc versions

That suggests someone went to significantly more effort than "just dynamically link it".

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

#206

Post by AshamedCaptain »

lmm wrote: post #205
AshamedCaptain wrote: post #201

Earlier quoted context omitted.

It has libc5 and glibc versions. It even has a version shipped as an rpm, which I guess makes it from 97. The rpm, by the way, also installs.

> It has libc5 and glibc versions That suggests someone went to significantly more effort than "just dynamically link it".

What effort exactly does it suggest? It ls literally dynamically linked with glbc.

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

#207

Post by X-Ryl669 »

fc417fc802 wrote: post #46
mdavid626 wrote: post #7

Earlier quoted context omitted.

You can "package" all .so files you need into one file, there are many tools which do this (like a zip file). But you can't take .so files and make one "static" binary out of them.

Well not a static binary in the sense that's commonly meant when speaking about static linking. But you can pack .so files into the executable as binary data and then dlopen the relevant memory ranges.

No you can't. dlopen signature takes a file path, not a memory range. And if you start to save the libraries to the filesystem before opening them, there's no difference to shipping an archive directly and skip the trouble of your own archive code.

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

#208

Post by uecker »

sebastos wrote: post #170
uecker wrote: post #145

Earlier quoted context omitted.

You call into dynamic libraries so that you do not need to recompile and distribute new binaries to all your users whenever there is a security issue or other critical fix in any of the dependencies.

But if I get to Bring My Own Dependencies, then I know the exact versions of all my dependencies. That makes testing and development faster because I don’t have to expend effort testing across many different possible platforms. And if development is just generally easier, then maybe it’s easier to react expediently to security notices and release updates as necessary.. .

You would need to monitor all your dependencies (and their dependencies), compile new binaries for all supported platform each time their is an issue (which you likely learn about later), notify all your user, and distribute improved binaries. I think this is far more effort than using dynamic libraries and compiling for a couple of Linux distributions. And I would be surprised if entities distributing statically linked binaries actually do this (properly).

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

#209

Post by stevefan1999 »

AshamedCaptain wrote: post #160
markus92 wrote: post #158

Earlier quoted context omitted.

We (small HPC system) just upgraded our OS from RHEL 7 to RHEL 9. Most user apps are dynamically linked, too. You don't want to believe how many old binaries broke. Lot of ABI upgrades like libpng, ncurses, heck even stuff like readline and libtiff all changed just enough for linker errors to occur. Ironically all the statically compiled stuff was fine. Some small things like you mention only linking to glibc and X11…

> Funnily enough grabbing some old .so files from the RHEL 7 install and dumping them into LD_LIBRARY_PATH also worked better than expected. Why "better than expected"? I can run the entire userspace from Debian Etch on a kernel built two days ago... some kernel settings need to be changed (because of the old glibc! but it's not glibc's fault: it's the kernel who broke things), but it works. > Now running stuff compi…

> it's the kernel who broke things

I remember this in a heated LKML exchange, 13 years ago, look how the table has turned:

>

> Are you saying that pulseaudio is entering on some weird loop if the

> returned value is not -EINVAL? That seems a bug at pulseaudio.

Mauro, SHUT THE FUCK UP!

It's a bug alright - in the kernel. How long have you been a maintainer? And you still haven't learnt the first rule of kernel maintenance?

If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs. How hard can this be to understand?

To make matters worse, commit f0ed2ce840b3 is clearly total and utter CRAP even if it didn't break applications. ENOENT is not a valid error return from an ioctl. Never has been, never will be. ENOENT means "No such file and directory", and is for path operations. ioctl's are done on files that have already been opened, there's no way in hell that ENOENT would ever be valid.

> So, on a first glance, this doesn't sound like a regression,

> but, instead, it looks tha pulseaudio/tumbleweed has some serious

> bugs and/or regressions.

Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious garbage and idiocy from a kernel maintainer again. Seriously.

I'd wait for Rafael's patch to go through you, but I have another error report in my mailbox of all KDE media applications being broken by v3.8-rc1, and I bet it's the same kernel bug. And you've shown yourself to not be competent in this issue, so I'll apply it directly and immediately myself.

WE DO NOT BREAK USERSPACE!

Seriously. How hard is this rule to understand? We particularly don't break user space with TOTAL CRAP. I'm angry, because your whole email was so _horribly_ wrong, and the patch that broke things was so obviously crap. The whole patch is incredibly broken shit. It adds an insane error code (ENOENT), and then because it's so insane, it adds a few places to fix it up ("ret == -ENOENT ? -EINVAL : ret").

The fact that you then try to make excuses for breaking user space, and blaming some external program that used to work, is just shameful. It's not how we work.

Fix your f*cking "compliance tool", because it is obviously broken. And fix your approach to kernel programming.

               Linus

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

#210

Post by lmm »

AshamedCaptain wrote: post #206
lmm wrote: post #205

Earlier quoted context omitted.

> It has libc5 and glibc versions That suggests someone went to significantly more effort than "just dynamically link it".

What effort exactly does it suggest? It ls literally dynamically linked with glbc.

It suggests someone went into the details of how it was linked and was careful about what it was and wasn't linked to, and perhaps even intervened directly in the low-level parts of the linking process.
Post reply on HN