This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Updated: libsigsegv{2}2.8-1


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]