Skip to Content.
Sympa Menu

freetds - Re: dbdead, PHP, and Apache

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Steve Langasek <vorlon AT netexpress.net>
  • To: TDS Development Group <freetds AT franklin.metalab.unc.edu>
  • Subject: Re: dbdead, PHP, and Apache
  • Date: Tue, 17 Sep 2002 15:14:14 -0500

On Tue, Sep 17, 2002 at 12:58:57AM -0400, James K. Lowden wrote:

> Got it, read it, thanks for the pointer. Read it before, without thinking
> I'd be responsible; the difference between trying to understand a language
> and trying to speak it. Even now, actually, it's not obvious to me anyway
> that the version had to be changed, since nothing disappeared from the
> source code interface.

The issue is that the soname is used at runtime by the linker to identify
libraries; that is, it's part of the *binary* interface. So if symbols
disappear from the library, it's important that programs not break when
the library is upgraded, and changing the soname is the way to do this.

> Understood. To make the future a better place, I would like to suggest we
> make a joint effort to keep the libtool version system in mind as we
> affect the public interface. If he who modifies the interface (including
> adding a function) updates its Makefile.am in accordance with the libtool
> system, everyone will benefit.

> For instance, AIUI, the ODBC lib is 0.0.0. I don't know; I never build
> it, but let's say so for argument's sake. The rules are:

It is at 0, for the record. However, I would actually argue that ODBC is
a special case, since the ABI for ODBC drivers is fixed in place by
Microsoft, and any changes to tdsodbc's interface should be bugfixes
only. Indeed, at least for Debian, I don't ship this as a shared library
at all, just as a plugin that can be used with driver managers -- so
library versioning is a total non-issue, AFAICT.

> 3. If the library source code has changed at all since the last
> update, then increment REVISION (`C:R:A' becomes `C:r+1:A').

> Yes: 0.1.0

> 4. If any interfaces have been added, removed, or changed since the
> last update, increment CURRENT, and set REVISION to 0.

> Yes: 1.0.0

> 5. If any interfaces have been added since the last public release,
> then increment AGE.

> Yes: 1.0.1? Or is that an "else" condition?

If both 4 and 5 apply, you would increment both, according to the libtool
rules. Although, I rarely pay much attention to anything after the
library major number ('CURRENT'), since it's the only part that's encoded
into the library soname.

> 6. If any interfaces have been removed since the last public release,
> then set AGE to 0.

> No: Leaving me with 1.0.0 (best guess) or 1.0.1 (interpreting the rule
> literally).

1.0.0 or 1.1.0, depending on the result of rule 3, I believe.


> > Is there any chance that 0.61 can be branched from 0.60 and released in
> > short order to address this library incompatibility? I can't upload a
> > FreeTDS package to Debian that breaks existing apps in this way, so I'll
> > either need to bump the soversion on 0.60 myself, or wait until 0.61
> > comes to term before I can get updated libs into Debian unstable.

> I will try to move quickly to offer you 0.60.1, along these lines:

> 1. checkout R0_60, plus head Makefile.am's. The Makefiles have not
> changed materially since the release.
> 2. apply the fixes you recommend.
> 3. tag as R0_601
> 4. cvs commit; make dist; make Steve happy ;)
> 5. update ibilio & readme.

> Howzat?

That would do it... :) Would it help if I went ahead and did the branch
for you from R0_60 and directly applied the (minimal) changes to CVS?

Steve Langasek
postmodern programmer

Attachment: pgp_TnuM9rT6x.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page