On Sun, Mar 09, 2008 at 10:58:21AM +0100, Murray Cumming <[EMAIL PROTECTED]> was heard to say: > > On Sun, 2008-03-09 at 14:27 +0800, Deng Xiyue wrote: > > Daniel Burrows <[EMAIL PROTECTED]> writes: > > > > > On Sun, Mar 09, 2008 at 12:52:57PM +0800, Deng Xiyue <[EMAIL PROTECTED]> > > > was heard to say: > > >> Daniel Burrows <[EMAIL PROTECTED]> writes: > > >> > If you want to help out, please do so. The main problem is that I > > >> > haven't had time to analyze the new release and see what's in it: is it > > >> > a release for new features, for bugfixes, for internal redesign; is it > > >> > source-compatible so that it can replace 2.0, or do I need to create a > > >> > new series of packages; if it's source-compatible, does it need a > > >> > soname > > >> > bump; etc. > > It's meant to be compatible. Like gtkmm 2.12 is compatible with gtkmm > 2.10. It adds API and removes some deprecated API. > > Even the removal of the deprecated API probably causes no ABI change, > because libsigc++ is mostly template code that is only actually > instantiated in the application itself.
I was worried by the "probably", so I did some investigation. objdump doesn't report any symbols exported by libsigc++ that include "SigC", and the string "SigC" doesn't appear to occur anywhere in the sigc++ shared library. In fact, the dynamic symbol tables of the two sigc++ versions (as determined by "objdump -T") are identical. Furthermore, a small test program written against the deprecated ABI runs fine with the new version of sigc++. I don't see any reason to expect ABI problems. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
