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.
> I can't even run a binary from one Linux distro to the other
[filename]: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by [filename])
The other way around works fine, though, and you can avoid it by statically linking the binary when you build it.
One of the recent efforts completed was removal of support for Ubuntu 24.04. That part I remember exactly :\
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.
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...
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.
More broadly, there are things like manylinux and MUSL which allow cross-distro applications.
As long as the container bundles the right libc, the program should work.