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.

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.

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.

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.