[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libc6 dependency generation



On Fri, Sep 27, 2002 at 11:01:15AM -0400, Brian White wrote:
> > > I was thinking about that.  What kinds of things count as an "ABI change"?
> > > If it was change to a passed structure (not just a mere extension) or
> > > something, then the library would not be backward compatible with apps
> > > built against earlier versions.  That leaves, as far as I can see, the
> > > set of functions/symbols exported by the library.  This, as long as
> > > the library still provided the older symbol set, could remain backward
> > > compatible.
> > 
> > If foo() takes an int arg, and is versioned @@GLIBC_2.2. Then it
> > suddenyly takes an off_t arg (which may be different on different
> > platforms, a new one will be created and versioned @@GLIBC_2.2.5.
> > 
> > Old apps will continue to use foo@@GLIBC_2.2, which is guaranteed to be
> > compatible. Just remember the whole reason for the versioned symbols.
> 
> So there will actually be two versions of "foo" in the new libc6
> library, then: one "foo(int)" and one "foo(off_t)", each with a
> different version on it to allow compatibility with older versions.
> Do I understand correctly?
> 
> What confuses me is why libc6 would make a change like that in a "minor"
> revision (as indicated by the version number of the package).  I would
> have expected the glibc guys to only redefine functions during the
> change of the "medium" or "major" revision numbers.

Minor releases they only require backwards compatibility, not forwards. 
"Medium" releases are huge.  The "Major" revision is reserved for
something which will require a global change of soname - which they
have no intention of allowing.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



Reply to: