FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Steve Langasek [mailto:vorlon AT netexpress.net]
> Sent: February 4, 2003 12:10 PM
> 
> 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.  
> 
> > 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; 

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)

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

OK?

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

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.  

Regards, 

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.