FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

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