Hacker News

points by jpablo 3 days ago | 0 comments

I can't even run a binary from one Linux distro to the other, let alone one from a random Unix from the 80s. If a rebuild from source is allowed (which would need to allow modifications to the build system) that's a completely different game.

[–] xattt 3 days ago

    > I can't even run a binary from one Linux distro to the other

Is this actually a thing?

[–] kragen 3 days ago

Yesterday I built a binary in an Ubuntu 24.04 Podman container and tried to run it on my Debian Bookworm system:

    [filename]: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by [filename])

Because I have glibc 2.36, you see.

The other way around works fine, though, and you can avoid it by statically linking the binary when you build it.

[–] fuzzfactor 2 days ago

In the last week or two I was looking at the changelog of an app or driver, might have been one shown here, maybe even cross-platform.

One of the recent efforts completed was removal of support for Ubuntu 24.04. That part I remember exactly :\

[–] jeroenhd 3 days ago

I had to run a Linux binary compiled for Ubuntu 10.something a few years ago. I couldn't get the drivers to work properly in libvirt and getting the binary to run on modern Linux was practically impossible, even with 32 bit support installed.

The downside of dynamically linked binaries: every tool of medium complexity needs a close-enough version of a common library, and once those get upgraded, the tool dies.

Most statically compiled version should work with a compatible enough libc, but I haven't seen many old programs like that.

Wine, on the other hand, runs tools from the 90s just fine, as long as they're 32 bit.

[–] account42 2 days ago

You don't need to go full static linking. Just bundle every library that doesn't have string backwards guarantees or rather bundle everything except base system libraires. The same is also how things work on Windows (and thus Wine really). Wine won't be able to run a binary that links to some random libpng or whatever that the compiler found in your System32. The only difference is that Microsoft makes an SDK that gives your some idea of whats a system library you can rely on as well as the ability to target older versions than the system you are building on. The latter can be done on Linux as well but there is no-pre made SDK so the easiest solution ends up being a VM or chroot with older libraries.

[–] Asooka 2 days ago

> Just bundle [...] everything except base system libraires

That means everything above libc. There are no "base system libraries" in the Linux world for GUI. Not even libX11, that has been deprecated in favour of libxcb, which has been deprecated in favour of not having X11 and running Wayland. Some days I am amazed that the ELF binary format hasn't been deprecated yet...

[–] account42 2 days ago

LibX11 is still alive and kicking. It is however possible to bundle libX11 and/or libxcb (libX11 today sits on top of libxcb) because the wire protocol between them and the X server is also backwards compatible.

And of course Wayland has XWayland to continue compatibility. This doesn't give you access to new toys but neither does restricting yourself to a 30-year old Win32 API.

And beyond libc/libX11/libxcb, libasound has also provided good backwards compatibility with newer systems implementing shims to make it work. You can also use libpulse directly if you don't care about old/opinionated systems though.

[–] boomlinde 3 days ago

AFAIK Wine will run 16-bit applications just fine now, through WoW64.

[–] 0x0203 3 days ago

Many programs are dynamically linked to at the very least, libc. If the system libc is older than what the binary was developed for, it will often fail. Failures going the other direction are less common, but can and do still happen. If the binary was statically linked with everything it needs, you've got a pretty good chance it'll work, but that's a bit harder to do with GUI programs that need to interact with X or Wayland.

[–] the__alchemist 3 days ago

It depends. I've found for example, if i compile on Ubuntu or Debian, it will probably work on any Ubuntu, Debian, or Debian-based distro released at or newer than the one I compiled it on. There are other cross-compatible examples.

More broadly, there are things like manylinux and MUSL which allow cross-distro applications.

[–] martijnvds 3 days ago

Containers fix this.

As long as the container bundles the right libc, the program should work.

[–] the__alchemist 3 days ago

I agree - the model I use for why containers (Docker etc) exist is to abstract over Linux ABI incompatibility. I don't think they're a great solution, as it complicates software distribution. I should be able to distribute an executable and have it just work.

[–] Rohansi 3 days ago

Linux isn't the source of the incompatibility. The kernel itself is very strict about not breaking userspace. Your userspace is breaking compatibility on its own, containers fix it by shipping the userspace components within the container, which only works because the kernel maintained compatibility. If the kernel broke compatibility you would need to use a VM so you can run a different kernel version.

[–] toast0 3 days ago

That's what win32 is for...

[–] the__alchemist 3 days ago

Hah well yes for Windows. This is a mercy, but my mindset is still "Works on Windows, Linux and Mac". (The last being dropped for anything that requires Cuda...)

[–] toast0 3 days ago

Win32 is the stable ABI for Linux, too.

[–] mrheosuper 3 days ago

Just like Python venv, The system is too broken that it's the only real practical fix

[–] dekhn 3 days ago

I've had static binaries on linux machines that worked across distributions for decades.