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? _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
