TLDR: Can't find it written down as an official commitment, though it seems to work in practice.
---
Hm. So I can tell you in practice I've used programs compiled against RHEL 5 on RHEL 7, and programs from Ubuntu 16.04 on 20.04, but that's not a formal commitment. It may be a limitation of my search skills, but I can't immediately find a formal policy/commitment. There's this:
> One of the GNU C Library's (glibc's) unwritten rules is that a program built against an old version of glibc will continue to work against newer versions of glibc.
...but that literally calls it an unwritten rule:)
There's this:
> The current GNU C library provides the run-time backward compatibility. That means executables and shared libraries built against the previous versions of glibc will continue to work with the current shared glibc, libc.so. This functionality is implemented with the symbol versioning in libc.so. This work is based on the effort from Eric Youngdale.
Dude! Thanks for all this context. This was great. I know I remember seeing a talk where Linus totally ranted over this issue in practice at some Debian conference some time ago.
I usually am able to get binaries running across distros myself but at times it involves messing with linker paths and setting up hacks symlinks. I don’t know what’s up with that or how it can be improved to “Just Work TM”
---
Hm. So I can tell you in practice I've used programs compiled against RHEL 5 on RHEL 7, and programs from Ubuntu 16.04 on 20.04, but that's not a formal commitment. It may be a limitation of my search skills, but I can't immediately find a formal policy/commitment. There's this:
> One of the GNU C Library's (glibc's) unwritten rules is that a program built against an old version of glibc will continue to work against newer versions of glibc.
- https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-...
...but that literally calls it an unwritten rule:)
There's this:
> The current GNU C library provides the run-time backward compatibility. That means executables and shared libraries built against the previous versions of glibc will continue to work with the current shared glibc, libc.so. This functionality is implemented with the symbol versioning in libc.so. This work is based on the effort from Eric Youngdale.
- https://mirrors.edge.kernel.org/pub/software/libs/glibc/hjl/...
...but that page talks about RedHat 6.2 in an active sense. Not RHEL 6.2, RedHat 6.2.
The final place I thought to look was to search through https://sourceware.org/glibc/manual/latest/html_mono/libc.ht... for "backward", but that seems to only talk about compatibility with BSDs and the like, not this.
So I got nothing.