From owner-freebsd-hackers Fri Jul 23 0: 4:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rebel.net.au (rebel.rebel.net.au [203.20.69.66]) by hub.freebsd.org (Postfix) with ESMTP id A3357156A4 for ; Fri, 23 Jul 1999 00:04:04 -0700 (PDT) (envelope-from kkenn@rebel.net.au) Received: from 203.20.69.80 (dialup-10.rebel.net.au [203.20.69.80]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id QAA07048 for ; Fri, 23 Jul 1999 16:30:12 +0930 Received: (qmail 50831 invoked from network); 23 Jul 1999 07:00:23 -0000 Received: from localhost (kkenn@127.0.0.1) by localhost with SMTP; 23 Jul 1999 07:00:23 -0000 Date: Fri, 23 Jul 1999 16:30:23 +0930 (CST) From: Kris Kennaway Reply-To: kkenn@rebel.net.au To: John Polstra Cc: Dom.Mitchell@palmerharvey.co.uk, hackers@FreeBSD.ORG Subject: Re: PAM & LDAP in FreeBSD, and userfs too. In-Reply-To: <199907230558.WAA75688@vashon.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Jul 1999, John Polstra wrote: > > On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: > > > > > > PAM is also "using masses of weird shared objects" but nevertheless it's > > > quite usable > > > > By statically linked binaries? > > Our PAM implementation works for static binaries too. See the > sources for the gory details. Basically it creates a library that > includes all the possible modules, and selects the right one at > runtime. There's some linker set magic involved. This means you can't add in a new module without recompiling the static library, correct? That seems to defeat the purpose of PAM being modular for the static case :-( Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message