Joe Nardone wrote:
> > That's what I say, too, but the libtool documentation says
> >
> > If any interfaces have been added, removed or changed since the last
> > update, increment CURRENT...
>
> Well, looking at
>
> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
>
> "Usually you can update libraries without concern; if there was an API
> change, the library creator is supposed to change the soname. "
>
> I think in this case we should acknowledge what GNU says, but we
> should do what actually makes sense for the community. It does not
> make sense to bump the SONAME when the API is backwards compatible.

I think the reason for libtool's note is that "update the libraries to
a newer version" isn't the only use-case it's protecting. There is also:

   - Compiling a program on one system and moving that binary to
     another system. If you don't change SONAME when entry points are
     added, on the other system when you run the binary you get errors
     about missing symbols, instead of errors about needing a
     different library version.

   - Packaging with RPM, DEP etc. The dependencies calculated by
     package managers for applications are typically derived from the
     SONAME of all dynamic libraries used by the applications and
     provided by lib packages. So when you build my-foo-program.rpm
     on one system, and offer it for install on another system, the
     packaging system calculates and requires libcurl-1.2.3.rpm to be
     installed. If the SONAME isn't bumped when new entry points are
     added, it's easy to get a situation where you give someone
     my-foo-program.rpm, and they install it and it fetches an
     appropriate libcurl-1.2.3.rpm from a standard repository (all
     nice and automatic), but the program doesn't run because _that_
     libcurl is missing the entry point.

-- Jamie
Received on 2008-05-23