[OpenAFS-devel] open issues for an openafs 1.8 branch

Garrett Wollman wollman@csail.mit.edu
Wed, 1 Oct 2014 18:40:35 -0400


<<On Wed, 1 Oct 2014 16:08:00 -0400, chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil> said:

> I guess you should ask openafs-users how onerous it would be for them
> to rebuild their local tools or how many have local tools linked
> against shared libraries.

Speaking for myself, my local tools are built against archive
libraries rather than shared libraries, because Debian at the time did
not ship shared libraries for OpenAFS.  I had to manually build a set
of PIC archive libraries in order to make my tools (which are
themselves delivered as a shared library), and I expect most such
tools actually take te form of a high-level-language binding.  (In my
case, my tools are written in Ruby and include a Ruby module wrapping
the protection server interfaces.)

One of the things you can do with symbol versioning is to mark each
symbol exported as being part of the official ABI or internal to the
implementation.  This page
<https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html>
describes how to do symbol versioning with GNU libtool, and also how
to hide internal-to-the-implementation symbols in shared libraries (if
OpenAFS isn't doing that yet).

-GAWollman