[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: linking of pam modules

> > Hmm. Does such kind of linking means that each PAM module will has its own
> > copy of functions from libpam? And if a stack of modules has 10 ones then
> > 10+1 copies of libpam will be in the memory?
> No.  From playing with libpwdb (which uses static variables for caching etc.
> .) linking a module with a shared-library at compile time seems to work as
> efficiently as you'ld hope.  This is my vague memory so if you know better
> please elaborate...

Let me add to my last post, because now I think this may be right.  (I'll 
try not to say much more, though, because I'm getting in over my head!)

It does seem that using the linking I suggested can cause libpam to be
opened twice (or, in your example, 11 times).  However, the code will all
be shared, and libpam doesn't have any static variables, so there should
be no extra memory use.  Right?  (If libpam did have static variables,
however, this would be a problem--if a library is dlopened twice, each has
its own copies of static variables.)

The other thing to remember is that if you create a binary that is linked 
to libpam at link time, you don't have to worry about this (I've verified 
that no extra libpams are opened).  It will only affect people doing 
"unusual" things--not linking to libpam, but dlopening it instead.

Lastly, I'll repeat that I found another way around my problem, so I don't
need the change anymore. 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []