This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Updated: libsigsegv{2}2.8-1
- From: Eric Blake <ebb9 at byu dot net>
- To: cygwin at cygwin dot com
- Date: Tue, 15 Dec 2009 20:54:27 +0000 (UTC)
- Subject: Re: Updated: libsigsegv{2}2.8-1
- References: <4B266F13.6070305@x-ray.at> <4B2788CB.3050306@byu.net> <4B27DDAB.3080503@x-ray.at>
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