On Mon, 23 Nov 1998, der Mouse wrote:

> * When linked static, dl_open() can't work unless/until we redo our
>    dynamic linker as a .a library for use by such applications.  (In my
>    mind, doing this defeats much of the purpose of linking static; when
>    I link something static I usually do it because I want a completely
>    self-contained executable.)  BSDAuth wins here.

I'm not fully versed in dl_open() & friends, but if done right, I think a
.a library for staticly-linked code is fine. All we have to do is make it
so that the .a library is enough for the uses we think NEED to use static
linking.

Said another way, as I understand it, we link /bin and /sbin staticly so
that they can run without /usr around - w/o dynamic libraries. As long as
PAM would cope with having its modules not around, we're fine. Can the PAM
interface report that a module's unavailable?

What would happen without modules around would depend on the authenication
system. If it's something like nsswitch, where there's a list of options,
as long as we had one of those options (and its module) in the static .a,
we should be relatively fine.

You're right that this basically has a staticly linked program looking for
shared libs, but if we do it right, it won't be NEEDING those libs, and
will thus hobble along w/o.

Take care,

Bill