"By default FPC programs and libraries do not use the C library on most platforms" (1) is what makes Free Pascal potentially interesting on Linuxes: sometimes the dependencies that exist when producing the binary using C or C++ simply disappear if one could write a Free Pascal program.
I haven't been able to use it in the environment I worked recently, but I had to waste so much time on the C and C++ library dependencies, different on different systems. Free Pascal seems to be a possible solution to that.
Using libc on Linux shouldn't introduce any incompatibilities (also you can use libc with Free Pascal, e.g. when using threads you link against the pthreads library which in turn needs libc and you can use libc's memory management functions instead of Free Pascal's own functions which can be faster), at least as far as glibc is concerned, since they are supposed to be backwards compatible. For example I have binaries compiled on 1998 Red Hat and linked against libc and libX11 working on two decades later distros just fine.
It is usually the libraries you use on top of libc and libX11 that tend to break and introduce incompatibilities.
C++ is another topic though, but i think there is an effort nowadays to avoid breaking that too.
> 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.
Yeah i was mainly referring to backwards compatibility.
And yes, AFAIK you can do that with Free Pascal, but i'm not sure if you link against libc if it'll generate versioned symbols (which cause the issue you mention) or not. I think it doesn't because you can crosscompile from Windows (or other OSes) to Linux so it shouldn't need any OS-specific dependencies. However it shouldn't be much of an issue even if it does since you can run the latest version of Free Pascal even on very old Linux distributions.
There are many cases where binaries compiled on older systems will not work on newer, despite no differences in APIs - this is due to Glibc going for "versioned symbols" instead of versioning ABI.
And of course there are cases, especially if you have C++ somewhere, where you have to bring not just glibc but also ld.so from the ancient system... (There's a big chunk of such libs packaged together to run Loki games ports on recent distros)
At least in my experience this has never been an issue with C programs (or C++ programs after getting the older C++ stdlib). I have a collection of old Linux game demos from late 90s and early 2000s and i tried them a couple of years ago in a modern distro and most of them worked (i had to use the oss-to-alsa bridge though). The games that didn't work were because of missing libraries that the distro didn't include, like -IIRC- Shogo needing Qt1.
Note that glibc also has non-versioned symbols. Versioning was introduced much later than the binaries i've mentioned i compiled with 1998 Red Hat were made. In addition the reason behind versioned symbols is to be backwards compatible so older binaries not working on newer systems because of versioned symbols would defeat the entire point of them existing in the first place.
> I have a collection of old Linux game demos from late 90s and early 2000s and i tried them a couple of years ago in a modern distro
Let me point again: I started the thread describing the opposite scenario:
Developing a program and delivering the binaries to the clients, including those who installed the OS on their server farms 10 years ago and not upgrading them, and who expect the binaries to "just work" there too.
That's why Red Hat and "Long Term Support" concepts exists: so that companies don't have to spend more time chasing the latest and greatest and totally irrelevant newest version of everything.
One wants to be able to deliver the products to them too, and avoid developing only on these old system, working around the bugs that were solved years ago.
The resulting binaries should just use what is available in kernel, and that's it. It's a real problem and it should be recognized.
Which results in funky situations where 22 year old binaries run, but a binary that is less than 4 year old can't - because unless you do extra work, you will get versioned symbols linked and you might be unlucky enough to fall out of the window of supported versions quicker than you think (Happened to me ~2013 when dealing with GHC at university, made for some really annoying weekend fixing binaries around)
I haven't been able to use it in the environment I worked recently, but I had to waste so much time on the C and C++ library dependencies, different on different systems. Free Pascal seems to be a possible solution to that.
--------------
1) https://wiki.freepascal.org/libc_library