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

The state of binary compatibility on Linux and how to address it

jangafx.com

Post reply on HN
Print view View original

91–100 of 145 posts

Re: The state of binary compatibility on Linux and how to address it

#91

Post by sylware »

vlovich123 wrote: post #8
sylware wrote: post #2

This article missed a critical point which is "the right way" to select a glibc ABI version: see binutils ld documentation, second part of the page related to VERSION support. This must include glibc internal symbols. This will allow to craft ELF binaries on a modern distro which will run on "older" distros. This is critical for games and game engines. There is an significant upfront only-once work in order to select…

Which works if you use binutils ld. Does it work with mold or gold? And then how do you use this with languages other than c++/c like Go or Rust?

Rust toolchain has already a bug since 2015: it cannot link statically libgcc, namely it does not have "-static-libgcc" option since 2015.

I got the bug with "TinyGlade" video game (extremely good BTW), which is written in rust, and with the dev we hit that bug. Namely... better have a libgcc with the right ABI... and I can tell you, this has a been a HUGE issue since valve started to distribute games more than a decade ago.

Re: The state of binary compatibility on Linux and how to address it

#92

Post by dpassens »

westurner wrote: post #56
moron4hire wrote: post #41

Earlier quoted context omitted.

It's interesting to think how a 20 year old OS plus one program is probably a smaller bundle size than many modern Electron apps ostensibly built "for cross platform compatibility". Maybe microkernels are the way.

How should a microkernel run (WASI) WASM runtimes? Docker can run WASM runtimes, but I don't think podman or nerdctl can yet. From https://news.ycombinator.com/item?id=38779803 : docker run \ --runtime=io.containerd.wasmedge.v1 \ --platform=wasi/wasm \ secondstate/rust-example-hello From https://news.ycombinator.com/item?id=41306658 : > ostree native containers are bootable host images that can also be built and sign…

> How should a microkernel run (WASI) WASM runtimes?

Same as any other kernel—the runtime is just a userspace program.

> Can a microkernel do eBPF?

If it implements it, why not?

Re: The state of binary compatibility on Linux and how to address it

#93

Post by flohofwoe »

mikepavone wrote: post #66

So of the 3 glibc issues they link - one is about the format of symbol information in the actual ELF binaries which is only an issue if you are not using the standard libc functions for looking up symbols for some strange reason - one is an issue that impacts targeting a lower version of glibc from a higher one which is a configuration that was never supported (though usually fails more loudly) - the last one is a se…

I think the problem in a nutshell is that it's not trivial(?) to build an executable on a modern Linux distro that links against an old glibc version number (and if it is trivial then it needs to be better communicated).

It is actually quite trivial when building with the Zig toolchain since you can simply append the requested glibc version to the target-triple (e.g. `-target aarch64-linux-gnu.2.xx`), but I think this doesn't work with regular clang or gcc (makes one wonder why not when Zig can pull it off).

Re: The state of binary compatibility on Linux and how to address it

#94

Post by ecef9-8c0f-4374 »

I bought 3 linux games on DVD between 2006 and 2016. I stopped buying linux games and instead started again buying windows games. Because there is no easy way to run them. On the other hand I can just run myst1993 and most of windows games without much hustle via wine. Wine is linux only stable abi

Re: The state of binary compatibility on Linux and how to address it

#95

Post by SSLy »

ecef9-8c0f-4374 wrote: post #94

I bought 3 linux games on DVD between 2006 and 2016. I stopped buying linux games and instead started again buying windows games. Because there is no easy way to run them. On the other hand I can just run myst1993 and most of windows games without much hustle via wine. Wine is linux only stable abi

> Wine is linux only stable abi

https://blog.hiler.eu/win32-the-only-stable-abi/

Re: The state of binary compatibility on Linux and how to address it

#96

Post by yx827ha »

flohofwoe wrote: post #93
mikepavone wrote: post #66

So of the 3 glibc issues they link - one is about the format of symbol information in the actual ELF binaries which is only an issue if you are not using the standard libc functions for looking up symbols for some strange reason - one is an issue that impacts targeting a lower version of glibc from a higher one which is a configuration that was never supported (though usually fails more loudly) - the last one is a se…

I think the problem in a nutshell is that it's not trivial(?) to build an executable on a modern Linux distro that links against an old glibc version number (and if it is trivial then it needs to be better communicated). It is actually quite trivial when building with the Zig toolchain since you can simply append the requested glibc version to the target-triple (e.g. `-target aarch64-linux-gnu.2.xx`), but I think thi…

Just to add some more context. Zig cc is a wrapper around clang. It can handle cross compiling to specific glibc versions. See https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace... I imagine it would help with the glibc problems they are taking about. Glibc tries to provide a backwards compatible abi.

Re: The state of binary compatibility on Linux and how to address it

#97

Post by guappa »

forrestthewoods wrote: post #78
mikepavone wrote: post #66

So of the 3 glibc issues they link - one is about the format of symbol information in the actual ELF binaries which is only an issue if you are not using the standard libc functions for looking up symbols for some strange reason - one is an issue that impacts targeting a lower version of glibc from a higher one which is a configuration that was never supported (though usually fails more loudly) - the last one is a se…

> then complain entirely about glibc That’s because when you’re trying to ship a product glibc is one of the primary sources of pain.

[flagged]

Re: The state of binary compatibility on Linux and how to address it

#98

Post by dataflow »

HexDecOctBin wrote: post #84
mikepavone wrote: post #77

Earlier quoted context omitted.

> It's the exception which is why it's talked about the most. It's definitely not the only exception. libgl is another obvious example since different GPUs need different userland code. I would be surprised if there there had never been compat regressions in those.

libgl can be dlopened, glibc can't be. That is the problem. If libgl has some incompatibility, I can try to work around that. If glibc has some incompatibility, my executable won't even launch. I agree with this article completely.

> libgl can be dlopened, glibc can't be. That is the problem.

What exactly prevents this for glibc? I assume you'd need a dlopen equivalent from somewhere for bootstrapping, but are there other issues (like TLS or whatnot)?

Re: The state of binary compatibility on Linux and how to address it

#99

Post by guappa »

ecef9-8c0f-4374 wrote: post #94

I bought 3 linux games on DVD between 2006 and 2016. I stopped buying linux games and instead started again buying windows games. Because there is no easy way to run them. On the other hand I can just run myst1993 and most of windows games without much hustle via wine. Wine is linux only stable abi

As if a windows game from 2006 is going to run on windows 11 :)

Re: The state of binary compatibility on Linux and how to address it

#100

Post by HexDecOctBin »

dataflow wrote: post #98
HexDecOctBin wrote: post #84

Earlier quoted context omitted.

libgl can be dlopened, glibc can't be. That is the problem. If libgl has some incompatibility, I can try to work around that. If glibc has some incompatibility, my executable won't even launch. I agree with this article completely.

> libgl can be dlopened, glibc can't be. That is the problem. What exactly prevents this for glibc? I assume you'd need a dlopen equivalent from somewhere for bootstrapping, but are there other issues (like TLS or whatnot)?

Yeah, TLS is one reason. I don't remember the details, but last time I looked into it, glibc abd the loader have some private interface that they use to load the program correctly, and there are no stability guarantees for this interface. Ideally, the loader and libdl will ship with the kernel, and glibc will have to use the public interface they expose.
Post reply on HN