[OpenAFS-devel] Shared library versioning and PIC

[Andres Salomon]

On Tue, 2005-05-10 at 00:36 -0700, Russ Allbery wrote:
> 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.

Excellent, I look forward to the PIC patch that debian's openafs
packages use going away (I just outright dropped them when I forward
ported the packaging to 1.3.82, since I don't particularly care about
the PAM module).


> 
> 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
> 

I would hope that OpenAFS libraries stick to ABI compatibility within an
SONAME; otherwise, the debian packages will end up having to be
processed manually (in NEW) for every new upstream version that is
released.  That seems like a major pain.


> 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?