[OpenAFS-devel] Current pthread PAM patch for Debian

Jeffrey Hutzelman jhutz@cmu.edu
Sun, 28 Aug 2005 22:50:45 -0400


On Sunday, August 28, 2005 18:44:02 -0500 Tracy Di Marco White 
<gendalia@gmail.com> wrote:

> On 8/26/05, Russ Allbery <rra@stanford.edu> wrote:
>> For any who might be interested, this is the patch I'm currently using
>> (against 1.4rc1) for building pthread PAM modules on Debian.  Yes, I know
>> the build hackery is ugly; I'm avoiding linking directly with the shared
>> libraries due to worries about stable ABIs.  I'm not proposing this for
>> inclusion in the mainline source, and note that these PAM modules will
>> leak threads if you use the nofork option with a long-running daemon.
>>
>> Note that this should work on other platforms besides Linux, but you'll
>> need to copy the Linux changes into the case sections for your local
>> platform.
>
> I've been looking at making OpenAFS work on NetBSD/amd64.  I have no
> problems with NetBSD/i386, with and without PAM (well, other than I
> have to use arla for actual client support), but on amd64 with PAM I'm
> seeing the need for the same type of hackery.  What would be the
> direction needed to go for making this work in the mainline source
> tree?

Russ's hackery is needed because he's trying to build PAM modules against 
the pthread versions of the libraries.  These libraries come in both shared 
and archive forms, but of course the archive libraries are not PIC, and 
thus are not suitable for use in the PAM modules on all platforms (they 
should work just fine on i386, but not on amd64).

However, the OpenAFS PAM modules are normally built against the LWP 
versions of the libraries, not the pthread ones.  I'm not entirely sure 
what Russ's motivation is in wanting pthread versions of the PAM modules 
(maybe there's a Debian policy, or maybe they have a threaded app that uses 
PAM), but it's not currently a necessary part of an OpenAFS platform port.

So, assuming you're happy using the LWP versions of the libraries, there is 
a much simpler (and, for the moment, more maintainable) solution available 
to you than what Russ is doing.  Simply arrange to have src/cf/osconf.m4 
set CCOBJ to include the flags necessary to build PIC code on your 
platform.  See the amd64_linux* stanza as an example.