FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

On Thu, Sep 19, 2002 at 12:43:27AM -0400, James K. Lowden wrote:

> I wonder about your logic, old man.  We don't implement the whole ODBC ABI
> by a long shot.  When we add interfaces -- albeit interfaces that "should"
> be there (for some value of should) -- doesn't libtool say we should up
> the version number?  Isn't half the game offering information to people
> and programs about what's different, irrespective of whether what came
> before was more-or-less in conformance?  

> Let me try that in English.  Aren't version numbers there to tell us that
> something has changed?  

> If we say "the ABI ... is fixed in place by Microsoft", OK, but how is
> that different at the end of the day from the case of db-lib?  Seems to me
> the spec is immaterial to the version number question.  

It's different because, from what I've been told, total
binary-compatibility with Sybase dblib/ctlib is not regarded as a
feasible goal[0].  (Maybe this feeling has changed since I last asked,
though?)  Binary compatibility with ODBC, OTOH, is a *requirement*
for any ODBC driver that will be loaded by an ODBC driver manager.

It really just depends on whether you regard the ODBC driver as a shared
library to be linked against directly, or as a plugin to be loaded
dynamically by the driver manager.

If you use FreeTDS headers to compile a program that links against the
ODBC driver, any ABI bugs will be reflected in the linking program; the
bug is symmetric and "cancels out", not causing linkage-related crashes.
But once that's done, making changes to the library ABI without bumping
the soname WILL cause crashes, so you have to change the library version
when you make a change.

If you're treating tdsodbc as a plugin, all the interface definitions
come from the driver manager, and anything in tdsodbc that deviates from
these definitions is a crash-me-hard bug.  Bumping the soname doesn't
gain you anything; if it was broken before you changed the interface,
there's not much you can do to make it worse. :)  And whether or not it's
less broken, the soname doesn't get used when loading the plugin.

In Debian, we only ship tdsodbc as a plugin, not as a shared library.  No
one's complained so far, so it seems just about everyone using ODBC is
using a driver manager.  But if you choose to support tdsodbc as a shared
library and bump the version number when changes are made, it doesn't
really matter for our purposes, because plugin loaders ignore the soname
completely.  It's just one more library for you guys to keep track of, in
that case.  If your gut tells you to version it, go right ahead; I was
just hoping to save you some maintenance overhead.

> Deferring to you, I didn't touch odbc/Makefile.am.  Left to my own
> devices, I would have selected 1.0.0.  (Up +1 from 0).  

> I added version information for ct-lib (0 1 0) and libtds (1 0 0) based on
> a diff of the nm output.  libtds is *very* different; behavior of ct-lib
> is consequently different.  

That sounds reasonable.

Steve Langasek
postmodern programmer

[0] Where complete binary-compatibility means that all function & struct
symbols provided by Sybase libs are provided by FreeTDS; the sizes and
alignments of all the structs is compatible; the return values and
arguments of the functions match; the *list* of libraries is identical
(Sybase's libct pulls in other libs that we don't provide); and the
sonames of all libraries match.

Attachment: pgpDnNjYZPOUJ.pgp
Description: PGP signature