FreeTDS Development Group

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

> From: ZIGLIO, Frediano, VF-IT
> Sent: Wednesday, September 21, 2005 3:32 AM
> 
> Well, although is a bit hard to speak about binary compatibility
> for ctlib I revised ctlib public headers to align declarations with
> Sybase ones. This certainly improve binary compatibility but also
> break existing 0.63 compatibility... The question is: should I
> commit this change? Is better to support a configure switch to
> decide which headers to use? I must say that 0.64 are not fully
> binary compatible with 0.63.  A small change (CS_BOOL is now int
> instead of unsigned char) make 0.64 not compatible. IMHO if we
> decide to change binary compatiblity we should follow Sybase one
> so in a future we can hope to produce a full compatible library.

Hi Freddy, 

Yes, please commit this change.  It's better, right?  The way I see it,
better is better. 

> Breaking binary compatibility means that if freetds is
> updated all dependent libraries must be recompiled. This is the
problem
> that cause debian to use a old version. 

Yes and no.  Debian at the moment lacks a maintainer for its FreeTDS
package.  If it had one, they'd be using 0.63.  Even if 0.61 and 0.63
*were* binary compatible, that wouldn't change the fact that 0.61
contained of lot of errors since fixed.  Upgrading is helpful,
compatibility or no.  

IMO this is a solved problem for freely available software.  Binary
compatibility changes mandate bumping the .so number.  Applications that
want the newer version have to relink.  It's inconvenient, but it works.


One solution for Debian users would be to document how to build a .deb
for FreeTDS, so they could  create their own package.  Anyone want to
offer?  I'd be happy to add it to the UG.  

> I think that we also did a big error packaging FreeTDS. If we can
> think about a binary compatibility for dblib/ctlib/odbc is very
> hard that libTDS would not change... the error is that freetds
> package very often contains libtds.so and libct.so/libsysdb.so
> libraries, so is hard to update package (libtds soname change
> frequently).  

The solution is very simple, no?  Don't provide libtds.so, or at least
don't link to it.  Instead link the client libraries only to libtds.a.  

$ ls -sk -c1 -S */.libs/*.a
1752 odbc/.libs/libtdsodbc.a
1592 dblib/.libs/libsybdb.a
1488 ctlib/.libs/libct.a
1288 server/.libs/libtdssrv.a
1176 tds/.libs/libtds.a
1120 tds/.libs/libtds_objects.a
  56 replacements/.libs/libreplacements.a

It's a rare application that uses two APIs, so static linking normally
won't increase memory use.  

I agree with you that there should be little need to change the .so of
the client libraries, given that they're well specified by the vendors.
It will take some effort, though, to make our header files match
(logically) what the vendors provide.  db-lib headers in particular are
difficult because Microsoft and Sybase don't always agree.  

Regards, 

--jkl

-----------------------------------------
The information contained in this transmission may be privileged and
confidential 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.  If you, as the intended 
recipient
of this message, the purpose of which is to inform and update our clients, 
prospects
and consultants of developments relating to our services and products, would 
not
like to receive further e-mail correspondence from the sender, please "reply" 
to the
sender indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New 
York,
NY 10105.