Re: libc6 dependency generation
> > 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.
> Now, for further reaching things like LFS, you have to enable that (like
> we do now). 99.99% of the time, glibc upstream will not create a change
> that breaks old apps. One example of a case where they did was nice()'s
> return value changing between 2.2.5 and 2.2.6, but that's only because
> the old nice() was just plain broken and wrong.
That makes perfect sense. Fixing a bug is fixing a bug. If it didn't work
correctly before then it doesn't matter if you change it.
Brian
( bcwhite@precidia.com )
-------------------------------------------------------------------------------
Sticks and stones may break bones, but words will shatter the soul.
Reply to: