Greg A. Woods wrote:
> 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).

If you have more than one process using a shared library, that library
is only loaded once, not duplicated like in the static linking case,
the way I understand these things work. And only pages which are used
are loaded. But hey, page granularity is at 4k, so there's still some
waste. Also, I think "ld" will load unrefernced object files regardless
- which doesn't happen with static linking.

> 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

This is - the way I see it is what's referred to as "DLL Hell" or
similar. This isn't a fault of shared libraries, but how they're
managed. This could be addressed in a way by putting a library in its
own directory (named with a version, crypto sum or some such to prevent
overwriting, etc.), and maybe make "ld" handle dependencies better in
some other ways. Why should we dump everything in one directory?

This is constantly a problem with binaries on Unix systems because of
the "Uh oh my executable depends on a library foo-bar-baz.so, because I was
compiled to use it, but you don't have it" syndrome. While you may
already have the same version, just named differently. Then that library
depends on others, and so on.

> I.e. most normal unix uses outside of a few desktop GUI implementations.  :-)

It all depends on the final goal. I think people use dynamic linking by
default even if their stuff could benefit from static.