Everything stated above is absolutely correct!The glibc compatibility issue can be addresses through compiling on the oldest distro possible. I personally do that in my CI pipelines and make debs for it, as well as archives users can freely use on any distro.
Then you have to address the libraries. To put it simply you have to statistically link each library so that you won't be bothered with specific version missing in a specific distro.
I have a software that runs gRPC, FFT libs, and a few more logging utilities, and it works great on my bleeding edge Arch after compiling it on an old Ubuntu container. Other binary-only closed source plugins I have, even the older ones, have no issues whatsoever.
The glibc while mostly backward compatible can in theory break after many years (it has in the past).
That's where Windows shine in having a more stable API.
The real time consuming problem is really to make something that compiles with Linux work with Windows including with all dependencies (or the other way around). It took me a few hours at worst to figure out the Linux glibc and static linking issues, but to support Windows and change compiler (I had due to gRPC only working with MSVC on Windows) and building utilities is a nightmare that took me months.
Here are some additional possibilities:Another way to avoid glibc compatibility issues is through containerization and sandboxing, like Fedora Silverblue does. Through the use of tools like Distrobox, Toolbx, Flatpak, etc, one can use any distro they like, and as many as they like, and run any program from one distro onto another. For example. I like and use Fedora. However, most programs are created to support the .DEB format. I could simply create an Ubuntu pet container on my Fedora machine, and run anything that is supported by Ubuntu. If I wanted to go further, I could also create an Arch container and install and run anything from the Arch repositories on my Fedora machine. My base machine would never see the glibc of the OSes in their containers, yet I could run those applications on my Fedora distro as if they were native. This is part of the beauty of Fedora's atomic distros, such as Silverblue. Silverblue goes one step further, and makes the base OS immutable.
From a developer's standpoint, this is useful to know, because if desired, instead of compiling on really old distros, one could simply use whatever distro is preferred. This is not to put down the idea of compiling on really old distros--in fact, compiling on really old distros is probably the best way to do it. However, knowing that users have the ability to do these other things on their Linux distros allows the developer to have options and choose what works best for him/her.
A developer could create virtual machines that have really old distros on them and compile a binary that would be compatible with newer non-ABI/API breaking glibc (and other) libraries.
Or, a developer can package their application as a Flatpak or AppImage or (heaven forbid) a Snap format and have a sandboxed application that works for any distro.
Or, a developer can simply choose the most popular Linux distro, and compile the binary on that, and then require users to make it work on their Linux systems in whatever means necessary, such as containerization like Distrobox or Toolbx.
It gives the developer choices. That's the key.
I LOVE the freedom in that! EDIT: Hehehe!! I just realized that I already spoke about this stuff a few months ago in this very same thread.
EDIT2: Wow! Even more embarrassing--I was the OP of this thread!!!
Statistics: Posted by audiojunkie — Fri Jan 03, 2025 9:13 pm