FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

On Tue, Feb 04, 2003 at 02:01:19AM -0500, James K. Lowden wrote:
> On Tue, 4 Feb 2003 00:26:37 -0600, Steve Langasek <vorlon AT netexpress.net>
> wrote:
> > 
> > I noticed in one of the previous release emails a mention that the SO
> > version had been bumped on libraries in preparation for the release.  I
> > don't doubt that this is warranted for the constantly-changing libtds
> > :), but I don't recall seeing any discussion of backwards-compatible
> > changes to the dblib ABI that would demand a corresponding SO bump.  Is
> > this a "just in case" thing, or can anyone point me to the relevant
> > changes that necessitated the increment?

> Guilty, your honor.  Among other things, I added the rpc functions. 
> Libtool says:

>   4. If any interfaces have been added, removed, or changed since the
>      last update, increment CURRENT, and set REVISION to 0.

But it seems step 5 was overlooked, which says:

  5. If any interfaces have been added since the last public release,
     then increment AGE.

This should give a -version-info string of 3:0:1, not 3:0:0; and assuming
libtool really does the right thing with these numbers <much crossing of
fingers>, the library will end up with a major number of 3-1 = 2,
indicating that binaries linked with libsybdb.so.2 previously will
continue to work with 0.61.

> So, that's what I did.  If you want dbrpcsend(), you need this .so, not
> last year's.  

Yes, but not forcing a recompile of applications that already built fine
in the absence of dbrpcsend is more important, IMHO, than trying to
embed information into the library telling people that they shouldn't
downgrade their library.  Packaging systems have other ways to
communicate the latter, accounting for the majority of binaries that
might be moved to machines running older libraries, so it's much less a
problem than the former.

-- 
Steve Langasek
postmodern programmer

Attachment: pgpi2ILMB5tck.pgp
Description: PGP signature