Skip to Content.
Sympa Menu

freetds - Re: [freetds] so version bump for dblib?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Steve Langasek <vorlon AT netexpress.net>
  • To: "'freetds AT lists.ibiblio.org'" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] so version bump for dblib?
  • Date: Tue, 4 Feb 2003 21:11:33 -0600

On Tue, Feb 04, 2003 at 01:39:22PM -0500, Lowden, James K wrote:

> > 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;

> Oh. I guess you want the *real* answer.

> I compared sybdb.h version 1.15 to 1.39. I didn't see any interfaces
> removed at first, but noticed:

> int DBTDS(DBPROCESS *dbprocess);

> That symbol is no longer exported. Instead we now have:

> int dbtds(DBPROCESS *dbprocess);
> #define DBTDS(a) dbtds(a)

Ok. The question is, was it really *ever* exported? :-)

$ nm -D /usr/lib/libsybdb.so.2|grep DBTDS
$

That's against libsybdb from 0.60.1, which is the earliest version that
bore the .2 major number.

> So I think I got the right answer by the wrong method. I want full credit
> anyway. ;-)

> OK?

I've been known to give A's for effort. ;)

When in doubt, it's better to err on the side of caution with the
versioning, as you've done. Still, I think it's worth trying to
eliminate the doubt if possible, to preserve binary compatibility.

> > 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.

> I was thinking more about specifying the version needed by a new
> application, but I clearly don't understand all this .so stuff yet.

> Not that that prevents me from having an opinion, of course: Don't you
> think it's odd that we eyeball two versions and use 3 numbers to represent a
> library's status? Here we are forcing a recompile based on the version
> number, but there's no way to say "we dropped DBTDS; if you weren't using
> that, you're OK". Neither is there a way to say (or easily locate)
> "function foo() now returns NULL instead of "" if no bar is found".

> In the former case, a database of C++ -style name-mangled functions would
> let a package manager or even an application know what's missing/changed and
> decide what it needed to do. The latter case is a semantic change that AIUI
> the libtool version numbers don't even try to address.

Well, gcc and the Linux ELF loader support per-symbol versioning, which
is what's allowed glibc to not bump its SO version in over five years in
spite of many, /many/ changes. But not every platform supports symbol
versioning (only Linux and FreeBSD that I'm aware of), so I've had a
hard time convincing people to adopt the non-portable technique... :)

Cheers,
--
Steve Langasek
postmodern programmer

Attachment: pgpcIWOINopk5.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page