[OpenAFS-devel] Shared library versioning and PIC

Russ Allbery rra@stanford.edu
Tue, 10 May 2005 00:36:59 -0700


As previously noted in a thread a while back, I'm in quest of shared
libraries for AFS.  The short term desire is to do something saner with
several PAM modules and get rid of a large and unattractive patch in the
Debian package to build a bunch of stuff PIC for the PAM modules.  The
long-term desire is to be able to package the AFS Perl module for Debian,
something that requires all of the code linked into it to at least be PIC.

The existing shared libafsauthent and libafsrpc libraries are sufficient
at least to call setpag, and are almost sufficient for the PAM modules
(thereby requiring at the least much less hackage).  I'd therefore kind of
like to use them, but that would require packaging them as shared
libraries, and that would require worrying about shared library
versioning.

I notice that the Makefile.in in the shlibafsauthent and shlibafsrpc
directories does say:

# API version. When something changes, increment as appropriate. 
# Ignore at your own risk.
LIBAFSRPCMAJOR=1
LIBAFSRPCMINOR=0

Should I believe that people are paying attention to that and honoring it?
Or would you welcome a patch to embed the current version into the shared
library name, so that the library would instead be, for instance:

    libafsrpc-1.3.82.so.1.0.0

That's the standard practice for libraries with an unstable API and allows
for packaging anyway (even though the libraries can accumulate a bit).

On a related note, it seems likely to be a little while before there's a
comprehensive shared library that contains enough stuff for, say, the AFS
Perl module.  Given that, would you be interested in a patch that allows
one to optionally build _pic.a versions of all of the libraries for the
use of projects that need PIC code?

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>