FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il mer, 2003-02-05 alle 04:11, Steve Langasek ha scritto:
> 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,
-- 
Frediano Ziglio <freddyz77 AT tin.it>