FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

On Mon, Sep 16, 2002 at 10:07:05PM -0400, James K. Lowden wrote:

> > > I think you're linking to the old libraries.  What says:

> > > $ nm /usr/local/lib/libsybdb.so.1.0 |grep -i dbdead
> > > 000036bc T _dbdead

> > Whoops.  Wasn't the stated plan to provide DBDEAD() as a
> > backwards-compatible alias to dbdead()?  Removing symbols without
> > bumping the soname is a library no-no.  If the DBDEAD() symbol is being
> > dropped altogether, I'd very much like to see a 0.61 release that fixes
> > the soname.

> I don't remember stating that plan.

Ok.  I should stop passing mailing list traffic through madlib filters
in my brain then, I guess. :)

> Thanks for pointing out the soname issue.  Do you have a handy-dandy
> reference for such rules, so I can hand pass it along to Release
> Engineering?  You know, I don't make the rules, I just work here.  

IIRC, the libtool info docs give a pretty good overview of the issues
surrounding library sonames.  The basic rule-of-thumb is that, once a
function (or other public symbol) has been included in a library release,
that function cannot be removed or have the sizes/types of its arguments
changed without incrementing the soname.  This ensures that the soname is
a guarantee of compatibility: as long as this rule is followed, any
library bearing a given soname is guranteed to be backwards-compatible at
the binary level with previous libs using the same soname, and therefore
it's safe to upgrade the library without breaking other software on the
system.

Since freetds uses libtool for building, the soname can be bumped by
editing the corresponding src/<lib>/Makefile.am file and changing the
-version-info line; the first number controls the library major number,
so changing it from 1 to 2 will solve the problem.

> Once I understand what to change where, I'll happily incorporate it in the
> next release.  

Is there any chance that 0.61 can be branched from 0.60 and released in
short order to address this library incompatibility?  I can't upload a
FreeTDS package to Debian that breaks existing apps in this way, so I'll
either need to bump the soversion on 0.60 myself, or wait until 0.61
comes to term before I can get updated libs into Debian unstable.

Thanks,
Steve Langasek
postmodern programmer

Attachment: pgpJV2ubnZEbb.pgp
Description: PGP signature