With all do respect. I'm not a developer/programmer: I know very little about it and have no experience with it. First of all I would like to thank @ScottWheeler very, very much
for taking Linux seriously and porting his plugin to Linux. You're the greatest man.
Linuxmusician01 wrote:I don't know nothing 'bout developing software so I could be offending people here which is not my intention.
Thanks for spelling this out
Linuxmusician01 wrote:The point is that some software development kits (that's what you call it, right?) support specific configurations of a system for which the software is intended
On linux, there isn't really a 'software development kit' in the way you describe - you just install the 'development files' of the libraries you want to program against, which typically are packaged in your distro's package manager.
Linuxmusician01 wrote:As a simple end-user it comes across like this: to simple little old me it looks as though development kit makers do not care about me as a user
It is certainly not about 'not caring about the user': when publishing open source software, while most of the time the maintainer is also a user of the software, doing it 'just for yourself' is not really worth it. So putting in all the work needed to publish the software is certainly a testament that open source developers certainly care about their users. Commercial developers of course also tend to care about their customers.
Linuxmusician01 wrote:They don't spend any time on assessing which versions of a library their stuff is really dependent. As a user I get the impression that the software in question does not rely on the new and improved things that new libraries offer. So they might as well be linked to older versions of the libs. So why don't they?
As I noted above, as a developer the easiest thing to do is just to build against whatever version is packaged with the distribution I am using during development. Building against specific versions is possible but cumbersome. Testing that the code also works with older versions of those libraries is possible, but "going an extra mile".
Linuxmusician01 wrote:Software that depends on old libs work with the newest versions, but not the other way around...
Unfortunately, this is not true: this is called 'keeping backwards compatibility', so software that depends on old libraries will also work with newer versions. To split hairs, this has 2 parts: 'binary backwards compatibility' (making sure projects written for an older version can link to a newer version) and 'source backwards compatibility' (making sure projects written for an older version can compile against a newer version).
The thing is, this is very hard - both in the sense that it takes a lot of effort, and that it is easy to get wrong.
This is part of the reason Ardour, when taken from the homepage, ships with its own version of the libraries instead of relying on the versions installed on your system. This has the advantage Ardour is not affected by compatibility problems when running on a system with unpredictable versions of those libraries. It has the disadvantage that any plugins loaded into Ardour also 'inherit' those versions of the libraries, making the plugins fail even when they were built for the libraries that ship with your distribution...
Linuxmusician01 wrote:Fact of the matter is that the latest version of MS Word probably still works on Windows XP.
Actually you'll need Windows 7 (https://products.office.com/en-US/buy/office
), but your point stands, that's also 9 years ago.
Linuxmusician01 wrote:But a drum plugin won't work on a Linux distro that is a few years old.
One thing to remember here is a plugin is a little more complicated than an application: because plugins loaded into Ardour 'inherit' the versions of the libraries shipping with Ardour, things are more complicated.
Linuxmusician01 wrote:I consider this to be one of the reasons people wont switch to Linux. I personally don't mind that much anymore because I don't care for the latest and greatest versions of applications: a version that is a few years old is good enough for me. I probably won't notice the "new" additions anyway.
For popular open source software, of course it is likely that this has been solved by the distribution: part of packaging is making sure a version of the software is built which works together with the versions of the libraries available in the distribution.
For obscure open source software, it might run, if any libraries it uses are either included (like with Ardour) or compatible with the versions on your system. If it doesn't, then you can try and build the project from source - perhaps making some adjustments to make it build against more modern versions of libraries. Building from source can be tricky, sometimes out of reach for 'regular users' - but it great that it is possible at all.
For proprietary software distributed as binaries, they are in a bit of a pickle: since the distributions won't take care of building their software, they must themselves make sure to build their software against libraries commonly found in distributions. That can be quite a challenge.
One commonly applied technique to distribute binaries that work across a number of Linuxes, already mentioned by Scott above, is by linking them statically. He is right to be careful about licensing pitfalls in this case, however: the same rules may not apply for static and dynamic linking.
scottwheeler wrote:in most cases using static linkage violates the licenses of the libraries that they're using (unless they're also shipping object files to allow the application to be re-linked, which I've never seen happen).
Scott: I wonder if that interpretation might not be too strict: indeed the LGPL allows static linking as long as you "also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application" (https://www.gnu.org/licenses/gpl-faq.ht ... cVsDynamic
). If you make sure you (also) ship your plugin in object format, it seems to me like that would be sufficient - it is not necessary to also ship the object files of the libraries you depend on, as the user can obtain/build those themselves.
Linuxmusician01 wrote:It appears to me (like stated more then once: from the targeted users perspective, I ain't no pro) that in this case there's a problem w/ hard linking to old libs by one app (Ardour) and dependency on a specific distro and specific libs of a second app (Sitala).
More generally, I think the problem is that different applications are sharing the same libraries. If one application could use one set of versions of libraries and another application could use another, that would already help a lot. There have been some packaging approaches (such as the previously discussed Flatpak
) that promote this idea, but I don't think any of those ever really became popular.
For plug-ins the problem is even more tricky. Treating plugins more like individual applications would help here, but it seems that isn't how VST works.
Linuxmusician01 wrote:Reminds me of the .net problem my friend had...
It would be interesting to know whether and, if so, how this is solved on Windows. They certainly used to suffer from that same problem ('DLL Hell'), but I haven't kept up. I suspect they either package libraries with their applications (Ardour-style) or link statically. Someone with more Windows experience should confirm, though.
Linuxmusician01 wrote:Why are dev kits so hungry on new libs? If they weren't we wouldn't have the problems w/ Sitala (it would have worked w/ the libs that Ardour wants to use etc.).
I hope the (slightly rambling) explanations above help understand some of the issues. As said, static linking of Sitala might already help a lot (though probably not with libc versions), and might not be as problematic license-wise as was suggested earlier.