raboof wrote:I'm curious why this appears to be less of a problem on Windows (I haven't done Windows development in ages), can you elaborate on that? You mention you "choose which version of the system you're targeting, and build packages for that version of the system", but that sounds like it is only true for the 'core system'. Above, part of what was problematic with libsitala as packaged for Ubuntu was a link to libcurl. Since libcurl does not come with Windows, all other things being equal you would expect Windows applications that use libcurl to have the same problem. But if I understand you correctly they don't. What is the difference? Do applications on Windows package their libraries with the application (a bit like the Ardour example), rather than sharing them? Or is there another distinction?
Unfortunately I can't give you a very satisfactory answer for Windows since I'm not an expert on the platform. I've worked on a number of products which I had to test on Windows, but I've always worked on them together with other people who were in charge of the Windows platform, so I've neither been in charge of packaging or deciding which libraries to use. (I do however know macOS fairly well in this regard.)
My impression is though that the lack of a well defined "core" set of libraries is part of the distinction. You'd typically statically link anything not included there. We don't use libcurl directly; it's brought in by a framework we use. On Windows and macOS that framework uses the system libraries to provide the function that's provided by libcurl on Linux.
In a way, the differences in the system evolved based on different selection pressure: Windows has a large stable SDK that has evolved to make shipping third party binaries as easy as possible. Linux reuses as much code as possible between applications which has advantages for memory usage and the ability to centrally patch bugs and security issues, but generally assumes that all packages for a system are being built centrally by the distribution.
Confounding things is that Linux isn't really one operating system, but a family of closely related operating systems. Slackware may decide to put config files in a different directory than Redhat or Debian or Gentoo. They may decide that even for a new release to stick to an old version of a library or compiler.
As a result, Linux projects usually have robust configuration systems in their source distribution to detect and adapt to these distinctions. But it also means that binary distribution for the entire family is difficult.
There was some attempt to address this with the Linux Standard Base some years ago, but my impression is that while it has improved the situation, it hasn't been as much as was once hoped.