[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Using libtool -release versus -version-info breaks packages (ITS#3035)

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

* kean@armory.com (kean@armory.com) wrote:
> > It was (is) allowing incompatible versions of the libraries
> > to be picked up dynamically (which is causing the usual
> > problems).
> There are ways to address that. See below.

If I understand correctly, these are actually not the only options
available, thankfully.  A much better option available on halfway recent
systems is to use symbol versioning.  This allows you to have multiple
symbols defined in the same library but have different versions for
them.  This means you can support, inside the same library and SONAME,
multiple ABIs.  This is exactly what glibc does, in fact, and they
havn't changed their SONAME since 1997 or so.  The difficulty with
implementing symbol versioning correctly is that it requires what some
may call 'overhead' in that you have to be aware of when you're making
an ABI change, or an API change and you have to update your versioning
script correctly when such changes are made.  It also means you have to
be very careful when changing code to fix a bug in an older version and
make sure that you don't change behaviour that was depended upon.

Certainly, symbol versioning makes packaging much easier and makes it
possible to link in multiple versions of a library safely (which is
happening more and more often as the complexity of programs increase).
Unfortunately, it's not supported on every Unix that ever lived.  Please
consider using it where it's available though and let the old Unixes
continue to do what they do today.

As one of the Debian package maintainers, if this isn't done by the
OpenLDAP core team we will likely have to do it ourselves, though we
won't be able to track every ABI/API change and will probably just use
the SONAME (which should correspond to OpenLDAP 2.1 or OpenLDAP 2.2) for
the version.  This isn't as clean or efficient but it will at least
handle the problem where two versions of the library are linked in at
the same time.  If OpenLDAP does decide to move to using '2.1.21' or
similar we'd probably be forced to correct that and manage the ABI
changes ourselves- the alternatives are much worse.


Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

Version: GnuPG v1.2.4 (GNU/Linux)