Re: Ardour still not present in testing
On Fri, May 2, 2008 at 8:41 PM, Paul Davis <paul@linuxaudiosystems.com> wrote:
> > Consider that the Ardour team do not want to be receiving bug reports
> > for years into the future from Debian, Ubuntu and other Debian
> > derivative distro users about problems which are not present in their
> > own copies of the libraries.
>
> There is really one library to which this specific issue applies, and
> that is libsndfile.
About libsndfile, how about the Debian libsndfile source package is
modified so that it produces a normal libsndfile library and a
libsndfile-ardour for ardour to build against. The ardour SConstruct
could then test that the changes are available at build time. If
libsndfile was using sourceforge, I'd suggest you hijack the project,
but that doesn't look to be the case.
Also, what about the clearlooks theme?
> However, the historical reasons are more pressing for us. Whatever
> debian (or any other distribution) maintainers may tell us, we know one
> thing for sure: there are plenty of users who will end up building
> Ardour with a different C++ compiler or even just sufficiently different
> compiler flags than were used to build the C++ libraries that Ardour
> depends on. The abject failure of the gcc project to maintain a stable
> ABI for C++ caused us to spend hundreds of hours of wasted time tracking
> down issues caused by these compiler mismatches. Our solution was to get
> rid of them for once and for all, by putting all the C++ libraries that
> Ardour uses (and that do not come with the compiler) into the source
> tree.
Only way I can think to deal with this would be some kind of
build-time test that checks the that the C++ ABI matches. Reading the
docs, there is -fabi-version=n, which might help here. The latest ABI
version mentioned there is version 2, which appeared in GCC 3.4 (4
years ago). The ABI change before that was in 2002. For some reason I
get the impression that ABI changes will be minimal from now on.
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/C_002b_002b-Dialect-Options.html#index-fabi_002dversion-120
> As a nod toward distributions like Debian, we added the SYSLIBS compile
> time option, but using it means that we will not provide any support to
> the user. Yes, we've heard for years that "there will never be a
> compiler mismatch, the user will always have the same g++ as was used to
> build libfoobar". Problem is, not a month goes by when this is
> disproved. We are *not* going to waste our time figuring out why the
> system build of libfoobar is breaking ardour when we already know that
> the build done as part of ardour's own build process works just fine
> (and I am not talking about code changes to the library, just the build
> processes). And its not just debian. Gentoo has had this problem
> recently, where their maintainer messed up their ebuild (using SYSLIBS)
> to produce a crash-on-startup version of ardour. Who do you think got to
> clean that up, us or the "packager" ?
Normally I would assume the packager did, but I guess from your tone
that you had to deal with it.
Not really any way to fix people not testing their changes, except
maybe forwarding all the bugs that get filed or asking for their
Gentoo commmit privileges to be revoked.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: