Subject: Re: PAM (dynamic linking, dynamic object modules, vs. static)
To: Dan Melomedman <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 09/26/2002 13:38:48
[ On Thursday, September 26, 2002 at 11:03:59 (-0400), Dan Melomedman wrote: ]
> Subject: Re: PAM
> Greg A. Woods wrote:
> > You have a strange outlook on these things.
> > "dynamic loading" does not equate to "modern" -- just because the
> > monkeys in Redmond are doing it doesn't mean it's a "good thing", nor
> > that it's even remotely modern.
> > Avoiding "dynamic loading" does not equate to "stagnation".
> Dynamic linking definitely has its place. I think it's overused, but it
> is useful. It can save memory, and it's a convenience feature.
Yes, I agree.
I was thinking more of dlopen() ala PAM than of shared libraries. You
won't necessarily reduce memory utilisation even when you need to
simultaneously support many different A&A methods if you use a separate
authentication daemon (eg. saslauthd).
Also, while the "convenience feature" is sometimes true, it can also be
an extremely huge mis-feature too when used incorrectly, such as it has
been so totally in pgksrc. For example I'm still trying to figure out
when and how to upgrade libpng on those systems where I haven't forced
it to be static-linked. There are a bunch of applications where libpng
is only used to create images and never to process foreign data, but as
it stands I cannot upgrade the applications which do process foreign
data without also upgrading and retesting all the others at the same
time. Even though in my production environment this list of
applications is very small, it does contain some of the most critical
ones, ones that require the co-ordinated efforts of many people to
sufficiently test and upgrade. If I had forced static linking in those
environments, like I have in some other environments, I wouldn't be
stuck like this.
> Though I
> think it's being used where it shouldn't also.
I.e. in most places outside the confines of huge over-bloated C++ and
similar applications which have several often/always-running processes
which do happen to share a lot of code (eg. KDE).
> binaries will load faster, so they're more suitable for busy fork/exec
I.e. most normal unix uses outside of a few desktop GUI implementations. :-)
> Linking statically when developing helps to show a programmer
> just how much bloat is being pulled into your executable, and which
> libraries are more bloated than others.
Not only that but static linking can help avoid symbol overloading and
it can make testing and debugging one hell of a lot easier during
Greg A. Woods
+1 416 218-0098; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>