Re: [ardour-dev] ardour

[Paul Davis <pbd@op.net>]

>It's about ardour, a Ardour is a multichannel hard disk recorder (HDR)
>and digital audio workstation (DAW) [http://ardour.sourceforge.net/]. An
>ITP was filed a while ago [http://bugs.debian.org/95870].  It is quite
>big, written in C++, making heavy use of jack, ladspa, midi, rt. =20
>
>Way back last year, Mandrake distributed a C++ library compiled
>with options, that caused ardour not to be compilable and/or showing
>strange behaviour, strange bugs...=20

This was not the only reason. Similar breakage occurs as soon as the
user acquires a C++ library in binary format that was compiled by a
g++ with either different options and/or a different ABI compared the
one used to compile and link the application. If someone upgrades from
g++ 2.95 to g++ 3.2, for example, and they fail to recompile *every*
C++ library on their system, problems will arise sooner or later
(depending on how many C++ apps they run and how they were built).

>Users complained they were not able to compile ardour because of these
>libraries and C++'s ABI instability.

They were able to compile things. If they could not have done this,
life would have been easier. Instead, they compiled them, and then
things didn't work.

>So Paul Davis (upstream) decided to include all C++ libraries except
>libstdc++ (I don't understand that exception) in the CVS tree. Namely

libstdc++ is currently distributed with g++. as a result, the
libstdc++ that you link against is more or less always compiled by the
same version of g++ used to compile the C++ program.

>libgtk-canvas, libgtkmm, libsigc++, libart. They are built along with
>ardour, compiled as static objects and linked statically.  The other C++
>libraries (libpbd, libmidi++, libgtkmmext, libardour) belong to ardour
>and are in the CVS anyway. The libraries having to do with GUI
>(libgtk-canvas, libgtkmm, libart, libgtkmmext) are statically linked
>into the ardour executable, the others are statically linked together
>into libardour (libpbd, libmidi++, libardour, libsigc++) which itself is
>shared.

this is not quite correct. libardour is the only one built as a shared
library. all others are statically linked into the final
exectuable. the shared library is just a development convenience - its
where the most significant changes happen and avoiding a static relink
every time that library changes its internals saves a considerable
amount of time.

>That makes the build process overly long and the binaries and the
>library overly large.

It also makes them stable and immune to compiler version SNAFUs.

>e) introduce a system to check the libraries for their correct
>   compilation flags at runtime (I have no idea how to do that)

this also needs to check the ABI of the compiler used. a library built
by g++ 3.2 cannot be used with g++ 2.95, for example.

--p