Re: [ardour-dev] ardour
On Wed, 11 Sep 2002, Paul Davis wrote:
> distribution of a C++ application, compiles it herself, and then links
> against libraries which she did not compile. thats where the chance
You mean against libraries she did not compile AND she did download from
This is what I call promiscuous activity, and it will get "diseases" into
her system. There is very little we can do about that, other than do what
it's been done for "real" diseases for which there are no profilatics yet:
teach people not to do that.
> for problems arises. it happened on redhat already, and i am sure it
> will happen again elsewhere, someday, perhaps even soon.
Many Debian developers (including me) don't have a very high opinion on
RedHat's shared libraries quality. We have had one too many major headaches
because someone in RedHat screws up and we have to somehow clean up the mess
(due to our feeble attempts to keep some sort of inter-distribution binary
I agree with you, it will happen again, somewhere.
> >Actually, there is if you don't mind patching ld and gcc. But it causes
> >more pain than what is worth, and it helps little. Here it is:
> nope. that won't solve all the problems. believe it or not, someone
> distributed a version of a C++ library compiled with -fno-exceptions
-fno-exceptions would change the internal ABI identifier, and therefore it
would be not linkable to libs with exceptions. The same goes for a LOT of
other optimization options.
> developer) to track down. i have a sense that there are a couple of
> other flags that could cause similar levels of problems.
> all it took to cause the problems for ardour last year was for redhat
> to ship gcc 2.96 along with some libraries that were either
> miscompiled, victims of gcc bugs, or both. redhat hadn't tested them
> enough; we were probably the first C++ application to be compiled by
> users (and that exercised C++ the way ardour does), and boom!
Oh, RedHat screwed up again. I hope they have proper procedures to avoid
such crap now... (we do in Debian).
> debian claims more rigorous testing because of the numbers of
> people. that might be true. the problems start when a broken C++
Not really. We might even have more clueful people, but what really helps
is the autobuilding and build-dependency (yes, we have runtime AND buildtime
dependencies) system, a healthy dose of paranoia from those few clueful
individuals we do have (and no relutancy whatsoever to LART whomever screws
up), and _no_ deadlines.
> you talk about this always as if the mere provision of certain
> functioning systems is enough to ensure that a user's experience
> matches what its "supposed to be". my experience is that this is
Bugs do happen, but we fix them, and I haven't seen any C++ breakage of this
kind (incompatible internal ABIs due to different compilers) in Debian for a
I would actually appreciate if gcc did some sort of sanity versioning on its
own to help us track down such bugs, but...
> >We are not asking you, Ardor upstream, to use our build system (although you
> >*are* welcome to). But it would be very helpful if you were not against
> >what would be done to Ardor's build system so that it can be added to
> its simply not possible to change Ardour's build system so that it
> doesn't use static linkage. this will break distributions that one way
> or another can't guarantee what debian does. if robert or anyone else
> has a patch to make it selectable, i will apply it.
You would not object to the debian source package directly patching the
build system, instead of providing a build-time selectable option? I ask
this because that's how it is usually done unless upstream is planning on
releasing such changes for all its users, or the Debian maintainer likes to
overengineer things :-)
The Debian source package is a "original tarball" (which would be the
tarball you distribute Ardor source without any changes, with very high
probability) and a "debian patch" that gets applied on top of it...
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot