Joey Hess writes: > ----- Forwarded message from Nathan Myers <[EMAIL PROTECTED]> ----- > > From: Nathan Myers <[EMAIL PROTECTED]> > Date: Sat, 15 Jun 2002 22:35:20 +0000 > To: [EMAIL PROTECTED] > Subject: C++ library packaging > X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 > > Hi Joey, > > I'm (re-)packaging some C++ libraries. > > Unfortunately the original packager failed to incorporate > dependence on the compiler/libstdc++ version in the name, so > that equal versions of the library, but built with different > compiler versions, cannot coexist. > > This is a general problem with C++ libraries (getting less so > as the compiler and library maintainers slouch toward a fixed > ABI), but is not mentioned in the policy manual. I'm guessing > we should incorporate the gcc-version in the package name, > like libxerces-gcc3.1_1.7.0-1.deb. The .so files, I suppose, > would have to look like lib/libxerces-gcc3.1.so.1.7.0.
shouldn't this be the libstdc++ ABI version and the G++ interface version? > I don't know how many C++ library packages there are in Debian > now, but they all need this treatment. > > Of more fundamental concern, the name for libstdc++ will have > to change, because libstdc++ from gcc-3.1 is not upward-binary- > compatible with the one from 3.0.x, so (IIUC) we can't have a > libstdc++.so.3.1. the shared object name already is different. why change the "basename" as well? > Fortunately, they have finally committed to > binary compatibility for all gcc-3.1.x, but will soon release an > incompatible gcc-3.2. (Probably all gcc-4.x.x will be at least > upward-binary-compatible.) > > I've been out of the loop for some time. Has there been any > discussion of this? Jeff Bailey <[EMAIL PROTECTED]> did some preparations for such an upgrade. Basically if Debian should change the sonames of the libstdc++ dependent packages or should do the transition in place. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]