On Sunday, August 28, 2005 20:02:09 -0700 Russ Allbery <[EMAIL PROTECTED]>
wrote:
Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
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.
Threaded app that uses PAM. (sshd, in particular.)
Ugh. Of course, sshd is not _actually_ a threaded app -- it starts up
pthreads for the exclusive purpose of running pam_authenticate in a
separate thread, in order to work around an architecture that would
otherwise make conversation.... annoying (though not impossible).
Maybe one of these days I'll see if I can come up with a proper fix to that
problem that doesn't involve running pam_authenticate in a separate thread
or, worse, a separate process.
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.
Note that this builds everything PIC; I'm not sure if you care. My
understanding is that there's a minor performance penalty. I'm not sure
if anything AFS does is such that you'd notice.
Last I checked, only those objects actually needed for the PAM module were
built with $(CCOBJ). Maybe that changed when I wasn't looking. In any
event, I'd be surprised to find a situation in which this has significant
impact.
-- Jeff
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
