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: Frediano Ziglio <freddyz77 AT tin.it>
  • To: FreeTDS <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] so version bump for dblib?
  • Date: 05 Feb 2003 09:55:24 +0100

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>





Archive powered by MHonArc 2.6.24.

Top of Page