>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
