Re: [ardour-dev] ardour
>If an user of a Debian stable system compiles all his C++ stuff using his
>Debian tools, and only gets binaries (i.e. stuff he did not compile himself)
>from Debian, he never hits any compatibilities.
that's true. its true of any distribution. the problem is not this
class of user. its the class of user who decides to use a source
distribution of a C++ application, compiles it herself, and then links
against libraries which she did not compile. thats where the chance
for problems arises. it happened on redhat already, and i am sure it
will happen again elsewhere, someday, perhaps even soon.
>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
(might even have been suse, i don't recall. it wasn't someone
disreputable). Ugly, fixable, but very hard for a user (or a
developer) to track down. i have a sense that there are a couple of
other flags that could cause similar levels of problems.
>"Building at home" is safe if you don't get binary crap from "untrustable"
>sources. At least as long as you are using something high-quality, I won't
>speak for other Linux distributions (but I very much doubt they ship
>something that much broken).
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!
debian claims more rigorous testing because of the numbers of
people. that might be true. the problems start when a broken C++
library slips through the door and users get it. there are only two
ways forward from there: either they don't know about the problem, and
it just bites them in mysterious ways, or they do, and they download a
new library. this new library was necessarily built at a different
time than the old one, and its there that the further mistakes can
happen.
>The Debian user can, and is encouraged to, build whatever crap he wants at
>home. It will all work fine as far as a constant toolchain can guarantee
>it, and *it bloody hell CAN* guarantee it for C++.
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
rarely the case. i recently did two debian installs from scratch, for
example, and found them both extremely difficult to get right. there
were unbelievable design/coding problems even with the very first step
of the first install (whichever version came before woody). when i
eventually looked into them, it was completely clear that they arose
from nobody ever have done the precise combination of things that were
involved in that install.
*if* everyone always uses the same toolchain, *if* libraries are
always built by the same person and always with the same
compiler/linker options, *if* users never install libraries from
outside this consistent system, then dynamic linkage will work and be
a good thing.
if it was me, i wouldn't want to bet my shoes, let alone my house, on
all those *ifs* being certainly true.
>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
>Debian.
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.
--p
Reply to: