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

Re: Slink to potato upgrade



On Mon, Mar 22, 1999 at 07:23:26PM -0800, Joel Klecker wrote:
> At 02:51 +0000 1999-03-23, Robert Woodcock wrote:
> >Greg Stark wrote:
> >This works - for apps that don't use libc-internal symbols that don't exist
> >anymore or have changed meanings. Apps that do are naughty. :)
> 
> Most of the symbols do still exist, but they are not global symbols anymore.

Looking at libtool.info [1], you'll see:

  1. Start with version information of 0:0:0' for each libtool library.

  2. Update the version information only immediately before a public
     release of your software.  More frequent updates are unnecessary,
     and only guarantee that the current interface number gets larger
     faster.

  3. If the library source code has changed at all since the last
     update, then increment REVISION (C:R:A' becomes C:R+1:A').

  4. If any interfaces have been added, removed, or changed since the
     last update, increment CURRENT, and set REVISION to 0.

  5. If any interfaces have been added since the last public release,
     then increment AGE.

  6. If any interfaces have been removed since the last public release,
     then set AGE to 0.

Let's say glibc 2.0 uses libtool version 0:0:0. glibc 2.1 is a "public
release", 2. applies.  The source code has changed, 3. applies. We have now
0:1:0.  According to Joel's statement (quoted above), 4. applies [2], now we
have 1:0:0.  I dunno about 5., but I'd guess it's not the case.  6. applies,
we have 1:0:0.  On linux, according to libtool's internal use of these
numbers, this produces libc.so.0.0.0 for glibc 2.0 and libc.so.1.0.0 for
glibc 2.1; it can't get any simpler than that.

I've been following this thread with interest, and from what I've understood
so far, if I use glibc as its _documentation_ says it should be used, I
shouldn't have any trouble; the problems arise when I use what glibc 2.0
_used_ to provide (but wasn't a _documented_ interface) but no longer does.
It's bad programming practice, it's true, but it's also true that it breaks
people's systems.  And that we should avoid.  That means _considering_ the
possibility of changing the soname, but also means _not_ doing it on our own
because that would render potato into a useless development plataform (in
some situations you can't _afford_ to recompile everywhere, you need to
provide compiled binaries)


					Marcelo

[1] Don't jump on me.  I'm just using what I think is a _good_ set of
    _guidelines_ regarding versioning of libraries.  I have _not_ said
    glibc uses libtool at all.

[2] The symbols were global.  Now they aren't.  A library interface has
    changed.  What glibc developers _think_ of the symbols doesn't matter. 
    What they actually _did_ with them does.


Reply to: