Retiring static libpam support

[Bruce Evans]

On Wed, 8 Jun 2005, Julian Elischer wrote:

> Dag-Erling Smørgrav wrote:
>
>> Currently, libpam is built both dynamically (with modules in separate
>> files which it dlopen()s, like everybody else does) and statically
>> (with the modules compiled-in).  This is a major headache, because the
>> static modules need to be built before the static library, but the
>> dynamic library needs to be built before the dynamic modules, so we
>> have quite a bit of magic (thanks ru!) to build libpam in two passes.

Actually, IIRC jdp did most of the work to support static linkage.  ru
just kept it working, unlike some maintainers (thanks ru :)).

>> There's also quite a bit of highly non-portable magic in OpenPAM to
>> support static linkage.
>> 
>> The funny thing, though, is that nothing in our tree acutally uses the
>> static libpam (unless you have NO_SHARED= in make.conf).  Therefore,

I use it all the time.

>> I'd like to remove the ability to build a static libpam altogether,
>> unless someone can come up with a very good reason not to.
>
> This may hurt me. I'll have to think about it..
>
> We statically link our applications to reduce problems with dependencies
> and we've just been moving the authentication side of things over to PAM.

This would hurt me if i ran -current.

> I gues it would be ok if the basic binary is static and the PAM modules are 
> loaded using dlopen.

I think dlopen() still doesn't work right with static linkage.  I don't
miss any dynamically loaded PAM modules since I don't need them.

Bruce