Re: Shared Libraries?

[Mark Johnson <johnsonm@xxxxxxxxx>]

On Feb 1, 2008 8:11 PM, Kyle Wheeler <kyle-qmail@xxxxxxxxxxxxxx> wrote:
> Generally, statically linked programs load faster than non-statically
> linked programs (see here for a demonstration:
> http://bulk.fefe.de/scalability/). Granted, you can still make static
> common libraries, but at that point all you're doing is making the
> code more complex without any real benefit---how often does the code
> in qmail.c change, after all.

No, dynamic linking is not free.  Prelinking can reduce the penalty
however.  As to your second point, I would argue that common
libraries, whether linked statically or dynamically, actually reduce
the complexity of the code, by replacing multiple copies of
functionality with one copy behind an abstraction layer.

I'm not talking about code specific to one package such as qmail, but
code that is shared between qmail, djbdns, daemontools and ucspi-tcp.
 Such as what goes into byte.a, cdb.a, unix.a, etc.

I've started comparing the cdb code in ucspi-tcp and djbdns.  It's
very similar, the only differences I've seen so far is that a lot of
the arguments are declared const in the djbdns version.

So why not abstract the cdb code out into a separate libcdb, with
provisions for linking statically or dynamically?  Let the user decide
which?  I think autoconf will do that with the proper dark
incantations (which can be clearly spelled out in  a README).  Sure,
it introduces new external dependencies to ucspi-tcp and djbdns, but
it would save them from carrying around duplicate cdb code.  Sure, the
code might not change much, but if it needs to be changed, the change
can be made to one place instead of multiple.