Moderators: khz, MattKingUSA
)Sounds good to me. To post to the wiki the forum / thread would be a help to discuss topics. I think there could be many different interests, variants, contingencies, aspects, possibilities, ... on these topics. You can't write these just like that.raboof wrote:I think forum threads are not great for long-term knowledge storage, the wiki might be better for that.
If anyone wants to discuss these topics then by all means open threads there of course - and ideally summarize findings in a more long-term place
I myself have problems with the program (with ~my distribution Gentoo) and have asked about it here.Linuxmusician01 wrote:@kHz pointed out, I'll stop harassing y'all now 'bout my install problems.
I completely understand where you're coming from on this. But this last assumption is unfortunately wrong. It's true on Windows, and it's true to a lesser extent on macOS, but on Linux, it's absolutely not a reliable assumption that software that works with old libs will work on a newer system.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, 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? Software that depends on old libs work with the newest versions, but not the other way around...
We were referring to the same thing with "object files" and "object format". It's something that I initially didn't consider, mainly because I've never seen any proprietary app take advantage of that portion of the LGPL. Things like, e.g. Reaper are statically linked, but as far as I can tell don't include their object files anywhere, so they're probably unknowingly violating the LGPL (which I admit is a subtlety easy to miss -- it's not intuitive that changing your compiler flags can result in a license violation). I'll play around with this and see how a statically linked Sitala fares. Back in the day (I was a very active Linux desktop developer in the early 2000s) you would still run into problems if you had two versions of the same library loaded into a binary because of global variable clashes and symbol collisions, but I think symbol visibility and thread safety may have improved enough at this point that it'd work. I'll give it a try.raboof wrote: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.
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.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).
I agree this is easy to miss - and I suspect many upstream projects don't actually feel strongly about this aspect of the license either...scottwheeler wrote:It's something that I initially didn't consider, mainly because I've never seen any proprietary app take advantage of that portion of the LGPL. Things like, e.g. Reaper are statically linked, but as far as I can tell don't include their object files anywhere, so they're probably unknowingly violating the LGPL (which I admit is a subtlety easy to miss -- it's not intuitive that changing your compiler flags can result in a license violation).raboof wrote:the LGPL allows static linking as long as you "also provide your application in an object (not necessarily source) format
Hmm yes, good point.scottwheeler wrote:I'll play around with this and see how a statically linked Sitala fares. Back in the day (I was a very active Linux desktop developer in the early 2000s) you would still run into problems if you had two versions of the same library loaded into a binary because of global variable clashes and symbol collisions
Here's hoping!scottwheeler wrote:but I think symbol visibility and thread safety may have improved enough at this point that it'd work. I'll give it a try.
Probably the difference is that I've written a lot of [L]GPL code, and as such am more familiar with the licenses. (Case in point: I wrote one of the libraries that Ardour bundles, and it's dual licensed MPL / LGPL specifically because the MPL does allow static linking without redistributing object files.) I suspect most folks porting music applications to Linux probably have less exposure to the OSS landscape.raboof wrote:I agree this is easy to miss - and I suspect many upstream projects don't actually feel strongly about this aspect of the license either...
I applaud you for being aware of the issue and holding yourself to a higher standard.
I fully agree. I was just afraid that I was going a bit to much off-topic which doesn't help me as a user nor the kind developer of this free piece of software. But you're absolutely right.khz wrote:I myself have problems with the program (with ~my distribution Gentoo) and have asked about it here.Linuxmusician01 wrote:@kHz pointed out, I'll stop harassing y'all now 'bout my install problems.
To make it clear: Everyone may and should be allowed to ask questions here! You, me, us, ... . User, developer, human, ... .
I think that how to develop programs for Linux / a distribution is a meta topic (libs, package manager, Ardour, KXStudio repositories, Flatpak, ..., what is ideal?).
Discussing this is helpful and doesn't mean that the user, developer, human can't ask!
Thank you too for clearing that up in layman's terms.scottwheeler wrote:I completely understand where you're coming from on this. But this last assumption is unfortunately wrong. It's true on Windows, and it's true to a lesser extent on macOS, but on Linux, it's absolutely not a reliable assumption that software that works with old libs will work on a newer system.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, 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? Software that depends on old libs work with the newest versions, but not the other way around...
This is why most applications create packages for every Linux version they're targeting.
With Windows and macOS you can choose which version of the system you're targeting, and build packages for that version of the system, and are mostly guaranteed that they'll work for that system or any newer one. That just isn't true for Linux. Linux regularly has changes that make older packages not work.
So the choice becomes, instead, "Which distros and which versions are the most popular?" In our case, the thing we've had asked for the most was Ubuntu LTS, so that was the first distro we packaged for.
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?scottwheeler wrote:on Linux, it's absolutely not a reliable assumption that software that works with old libs will work on a newer system. (...) With Windows and macOS you can choose which version of the system you're targeting, and build packages for that version of the system, and are mostly guaranteed that they'll work for that system or any newer one. That just isn't true for Linux. Linux regularly has changes that make older packages not work.
Ubuntu LTS is based on a Debian sid?scottwheeler wrote:That's why for now we just released a package for the most recent Ubuntu LTS, since that had up to now been the most requested distribution.
While some distros do include non-OSS software in their default repositories, my impression is that it's usually only stuff deemed sufficiently important -- things like (historically) Adobe's Flash Player, or proprietary graphics or wi-fi drivers. I'm skeptical Sitala would meet that standard.Linuxmusician01 wrote:Fortunately now-a-days almost all software (that I use) is in the standard repo of a distro or in KXStudio's repo. Do you think your plugin will make it into the standard repo of a distro? Or in the KXStudio repo? That may be a completely different discussion altogether, my apologies on beforehand for the off-topic...
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.)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?
All of Ubuntu is forked off of Sid, but there's a long process which turns those into Ubuntu releases. LTS is their "long term support" release, which they do every couple years, is intended to be particularly stable, and is supported by Canonical for 5 years. Again though, I'm not in the business of telling people which distribution they should be using. Ubuntu and its derivatives were simply the things we got the most requests for.khz wrote:Ubuntu LTS is based on a Debian sid?
From a programming point of view this is not a problem? Debian sid is quite exciting sometimes (bugs, system changes (libs), update, ...), isn't it?
It's good to use, no question - I'm using Gentoo sid - but from a programming point of view I imagine it to be stressful.
Code: Select all
/opt/ardour/lib$ LD_LIBRARY_PATH=/opt/ardour/lib/ /opt/ardour/lib/ardour-vst-scanner -f /usr/lib/lxvst/libsitala.so
[ERROR]: Could not open existing LXVST plugin: /usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0: undefined symbol: atk_component_scroll_to_point
[WARNING]: Cannot get LinuxVST information from '/usr/lib/lxvst/libsitala.so': load failed.Code: Select all
$ uname -a
Linux windowsrefund 4.18.0-12-lowlatency #13-Ubuntu SMP PREEMPT Wed Nov 14 18:08:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/apt/sources.list | grep -v ^# | grep -v ^$
deb http://us.archive.ubuntu.com/ubuntu/ cosmic main restricted
deb http://us.archive.ubuntu.com/ubuntu/ cosmic-updates main restricted
deb http://us.archive.ubuntu.com/ubuntu/ cosmic universe
deb http://us.archive.ubuntu.com/ubuntu/ cosmic-updates universe
deb http://us.archive.ubuntu.com/ubuntu/ cosmic multiverse
deb http://us.archive.ubuntu.com/ubuntu/ cosmic-updates multiverse
deb http://us.archive.ubuntu.com/ubuntu/ cosmic-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu cosmic-security main restricted
deb http://security.ubuntu.com/ubuntu cosmic-security universe
deb http://security.ubuntu.com/ubuntu cosmic-security multiverse