Le sam 31/08/2002 à 17:18, Paul Davis a écrit : > 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). This is the work of the distribution to get it right. Debian has already plans to make a smooth G++ transition without breakage. This does not justify at all the use of static linking (which is evil imho). > 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. Debian users don't have to compile things. This is the maintainer's work, helped by the autobuilders. Moreover, the build dependencies can guarantee you the package will build fine if you try at home. > 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. No, the shared library is a user convenience. It avoids rebuilding everything that depends on a library after a security update. It avoids bloating the hard drive with static binaries. -- .''`. Josselin Mouette /\./\ : :' : josselin.mouette@ens-lyon.org `. `' joss@debian.org `- Debian GNU/Linux -- The power of freedom
Attachment:
signature.asc
Description: PGP signature