X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00,SARE_SUB_ENC_UTF8,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: Updated: =?utf-8?b?bGlic2lnc2VndnsyfTIuOC0x?=
Date: Tue, 15 Dec 2009 20:54:27 +0000 (UTC)
Lines: 43
Message-ID:  <loom.20091215T214029-795@post.gmane.org>
References:  <4B266F13 DOT 6070305 AT x-ray DOT at> <4B2788CB DOT 3050306 AT byu DOT net> <4B27DDAB DOT 3080503 AT x-ray DOT at>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Reini Urban <rurban <at> x-ray.at> writes:

> >> The DLL revision is bumped from 1 to 2.
> >
> > I'm curious why you bumped the dll revision when building 2.8.  I don't
> > see any backwards-incompatible API changes compared to 2.6 that would have
> > required the bump; am I overlooking something?  But the barn door is open,
> > now that you have released clisp depending on the new dll revision.  So
> > I'll now have to rebuild m4 to pick up the new dll version.
> 
> Me neither. It was not me, it was Bruno Haible, upstream.
> But there must be some changes.
> LIBSIGSEGV_VERSION_INFO = 2:1:0
> 2.7 had 2:0:0
> And 2.6++ started with 1:0:0

According to the libtool versioning scheme, 
http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info, 
the change from 2.6 (1:0:0) to 2.7 (2:0:0) requires a dll version bump on the 
surface (the 'current' field changed from 1 to 2 to mark an interface change, 
and the 'age' field reset to 0 meaning that the change is not backwards-
compatible).  But reading the NEWS file, the only documented change was Linux-
specific ("the type 'stackoverflow_context_t' is now typedefed to 'ucontext_t 
*' rather than 'struct sigcontext *'"), so we probably could have survived 
without a dll rev bump.

Meanwhile, the change from 2.7 (2:0:0) to 2.8 (2:1:0) implies complete 
backwards compatibility (the 'revision' field changed from 0 to 1 to reflect 
that code changed to fix bugs, but neither 'current' nor 'age' changed so 
nothing was backwards-incompatible).  And the NEWS appears to back this up, 
with no mention of any interface changes.  But certainly an argument for 
leaving the dll version unchanged.

Just so I'm clear, is the dll version something you manually pick based on the 
libtool version changing, or is it something generated automatically by the 
default build process (either by libtool or by cygport)?  I guess that if the 
version suffix is automatic, based on the fact that the 'current' field changed 
from 1 to 2 between 2.6 and 2.8, then you did the right thing, even if the 
interface change that Bruno based his version bump has no effect on cygwin.

-- 
Eric Blake



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple