glibc is perfectly backwards compatible. We still build software on Debian 7 (glibc 2.13 from 2011) and the binaries works just fine on Debian 11 (and also on m

glibc is perfectly backwards compatible. We still build software on Debian 7 (glibc 2.13 from 2011) and the binaries works just fine on Debian 11 (and also on most other glibc-based distributions). But you need to be careful to only use libraries that provide long-term binary compatibility. Most libraries you can find in the system package manager don't do this. Also, on Linux it's weirdly difficult to do it the other way around: use the current distribution to build binaries that also run on older distributions. On Windows this is trivial: I can develop on Windows 10, with the current VS2019 and the current Windows 10 SDK, and a simple "#define _WIN32_WINNT 0x600" is sufficient to make my binary work all the way to Windows Vista (2006). On Windows it's normal to ship libraries in the application directory instead of depending on a global /usr/lib/ installation; so non-Microsoft libraries that don't maintain a stable ABI are much less problematic. Also, good luck if you're on Linux and want to use an up-to-date gcc (e.g. gcc-8 for C++17 support) on an older distribution. Building gcc from source is easy, but the resulting gcc-8 will produce binaries that require symbols from libgcc-8, which the system libgcc won't have. We actually ended up patching gcc to disable the optimizations that introduce uses of new symbols not yet present in deb7 libgcc.