For some time there have been reports on IRC from users of various Linux distributions that some feature of Ardour is broken. It is getting increasingly tiresome that we end up as the frontline support for breakages that are distro-specific and that we cannot control. These problems waste my time. It would be nice if they would go away. Meanwhile, here's what distribution users can do:
Ubuntu
The common complaint here is the import dialog in Ardour doesn't work. This breakage is caused by whoever built the Ubuntu package for Ardour. Ubuntu users can:
Download a newer package, perhaps from here or here
Build Ardour from source themselves.
Make sure the existing "official" packagers are aware of this issue.
Gentoo
Problems in Gentoo ebuilds are more subtle, but more widespread. The official ebuilds enable a compile-time option that we (Ardour developers) explicitly note as being unsupported. There is no good solution here, but a middle ground is to use the
Pro Audio Overlay 2.999 ebuild with DISABLED(USE=-syslibs). We'd be happy if Gentoo users pointed this out to the ebuild maintainers.
Another option is to install a distribution in which Ardour works out of the box! I have had excellent luck with the Debian-based (soon to be Ubuntu-based) 64 Studio. Freebob worked as soon as I installed version 1.1, and they plan to have FFADO support in version 3 which is currently in beta.
Of course, 64 Studio is a purpose-built distro – so if you want to do anything other than media creation with that box you may have to do a dual-boot or pick a different distribution.
The Ubuntu developers know about this issue: https://bugs.launchpad.net/ubuntu/+source/ardour/+bug/279723
but since 8.10 is the only release affected, and because the RT kernel in 8.10 is also quite bug ridden, audio users are just advised to stay with 8.04LTS at least until 9.04 is released in April. Unfortunately, some users are not getting this message.
This issue is fixed in 9.04 and efforts are underway to backport a newer Ardour to 8.10 and 8.04.
I’m not the SUSE packager, but let’s take a look at the OpenSUSE ardour2.spec for ardour-2.7.1
└» grep SYSLIBS ardour2.spec
SYSLIBS=1 \
Tadaaa. It also applies this one: ardour-2.5-gcc43.patch
Why? Because the internal libs are somewhat broken, don’t compile with gcc-4.3 and so cause a shitload of more work for packagers that are already busy with tons of other packages too.
So one has to take care of the libs ardour includes even twice: once for the system, and another time for ardour’s internal ones?
You really must be joking.
Just remove that SYSLIBS=1 thing, piss off all packagers, and then prepare yourself for being busy all day answering poor users that ask you how to fix that ton of compile errors. For sure nobody will ask you about any GUI bugs anymore, as nobody will get that far on a somewhat recent distribution.
You should be happy that packagers do that, and what you actually should do is to clearly tell users that they should first head to the bug tracker of their respective distribution. Most of the time the packagers will be able and are willing to fix that, and if all goes wrong you’ll receive one question per common issue and distribution, by the packager in charge.
Teekay - we’ll be happy to mark the SuSE packages broken as well, in that case. Or perhaps you’d like to come and hang out with us on IRC, and we’ll let you field the questions from SuSE users about wierd errors. You can hand them off the the SuSE support network(s) and get the SuSE packagers to pass patches back upstream to us (I’m not sure I ever recall hearing from them about any issues at all).
The complaint about gcc 4.3 is odd, since most of Ardour’s core developers all use it. We don’t see compile-time errors, and neither do our beta testers who are also using gcc 4.3. I have gcc 4.3.2 installed on both a x86_64 (amd64) and x86 (P4) system right in front of me, and Ardour compiles without error on both. SuSE-specific error?
The problem with Gentoo ebuilds is not tested with the official ebuilds, but rather with the pro-audio overlay ones. ONLY the 2.9999 ebuild allows you to disable the SYSLIBS, the other ebuilds do not have the option, and as a result we can’t really support them.
There is an inherent conflict between software developers and distributions. Developers want the latest stable version of their code to be the current version and with something like ardour that often means specific versions of things like gtkmm, and sometimes those versions are actually snapshots, not current stable releases.
For a packager this presents a major headache. These dependencies aren’t always on stable releases /from the perspective of other software/, and there is the general principle that libraries are supposed to be shared. It’s unsustainable for every package to ship with its own favoured versions of its dependencies.
To further complicate matters here (and I wear my allegiances on my sleeve here as I am a lapsed Debian developer), distributions have different goals and standards of quality. Debian tends to favour a very technically correct approach, for someone’s interpretation of “correct”, which in turn also can lead to them being behind the curve. Historically the commercial Linux vendors have tended a little more towards releasing with star studded feature sets in time for trade shows or whatever, but perhaps riddled with bugs and releasing as finished code that was never intended by the developer to be a stable release. On top of that you get the “community released” packages. This may work for Red Hat et al but for Debian this certainly used to be a nightmare because the quality and standards adherence was often very low, and this could have a knock-on effect. They are a well-managed distribution’s worst nightmare.
I think the only real answer here is more communication (I know, more time) with the distributions. Perhaps we could have a fairly prominent page, perhaps on the download links, with a table of distributions and a rating for their support for Ardour. Full marks would go to those distributions for which we knew the packagers, they worked closely with us and actively helped in sorting out real bugs from distribution bugs.
@bjb - i think you’re missing the bigger picture here. This is not about shared libraries and sharing in general. Historically there has been one library in Ardour that we have included because we want “our dependency” included - libsndfile - and this was because a new version of that library with our patch in it took a very, very long time to come out. Other than that, we have never bundled libraries for this reason.
However, this story is really about C++ and libraries, not library sharing in general. Because of the historical instability of the g++ ABI, and because of certain features of the language itself, it has been exceptionally difficult for developers of C++ applications for Linux to place any trust in the C++ runtime environment that already exists on the machine. The only exception is libstdc++, which is provided as part of the compiler and can be assumed to be usable.
Many packagers (not all, but some) and many commenters on shared library policies for distros do not understand (or forget) that C++ shared libraries have a set of problems not shared with C shared libraries, and they insist on a common policy for both. Their policy is correct if the extra potential problems with C++ libs can be shown to be absent, but its incorrect in enough cases (not a majority, just enough) that it causes problems for independent software developers.
Nobody has yet developed a tool that could test the runtime environment and decide if the C++ libraries appear safe to use. It is not a trivial task.
Well, imho no one is perfect …
application developers, packagers, documenters, … everyone can make mistakes.
So I think the best way to achieve optimal results is to get in touch with the “responsibles” by submitting bug reports/sending an email/etc.
OK - to some extent it is - I can use the import in the distro-package but my german version does not fit in the width of my 1200x800 Laptopscreen…
I use to compile Ardour from source - I never have seen any distro-package be it Ubuntu, CCRMA, Suse or even 64Studio that was the same as good as a build from source (though the package for Suse 111 comes near…)
Further information from the Fedora Project on their stance is found in their bugzilla, bug # 339391. That’s at bugzilla.redhat.com, search for that bug #. Current Fedora still has SYSLIBS=1 enabled in the specfile, for Fedora 12 and Ardour version 2.8.2.
I will be reviewing whether some odd behaviors I have seen are traceable to this decision (made back in Ardour 2.4 days) by Fedora.