> I have binaries compiled on 1998 Red Hat and linked against libc and libX11 working on two decades later distros just fine. The goal was avoiding to use "199

> I have binaries compiled on 1998 Red Hat and linked against libc and libX11 working on two decades later distros just fine. The goal was avoiding to use "1998 Red Hat" to compile today something that should work on a few years old system. That is the direction that is typically broken with C and C++, to the point that only safe approach is, indeed, to use 1998 Red Hat. But using 1998 Red Hat forces you to use the very old compilers and old anything else on that same Red Hat, which is what could be very inconvenient in 2020, when one has to use other tools with newer features in the process. If I understand, I can use 2020 OS and using Free Pascal trivially produce binaries that would work on the older systems on which the C and C++ binaries produced on the 2020 OS just wouldn't. Edit, answer to the post below: > i'm not sure if you link against libc if it'll generate versioned symbols If I understand correctly, one can produce Linux binaries with Free Pascal while depending only on Free Pascal's libraries which don't have libc dependencies at all. And that is what I see as a huge potential to produce the binaries that don't break on older Linux version, the way libc-linked typically do not because Linux kernel is incompatible, since it isn't, but just because GNU libc infrastructure allowing only "build on older Os for newer" but not at all the opposite scenario.