[Talk] State of dynamic linking in various platforms...

[Peter Jeremy]

On 2002-Aug-22 14:50:32 +1000, Michael Paddon <michael at paddon.org> wrote:
>Statically linked executables have several key advantages IMHO:
>   * faster (no run time linking necessary, but who cares with an n GHZ
>     processor)

Runtime linking generally implies PIC for the shared libraries - on
most systems, this means you lose a register (it's needed to support
PIC).  On the iA32, the loss of a register is a further performance
hit (since there aren't many to start with).

And as for speed, we have some applications that take 10 seconds of
CPU time (on a fast Alpha) to start - courtesy of the runtime loader
(and that's with lazy function binding, so the 10 seconds is just to
bind variables).  We would love to be able to statically link them...

The "buy a faster processor and more disk space" approach leads to
abominations like WinBloze.

>All that being said, I reckon that the memory efficiency issue trumps
>all for system executables. Make everything dynamic.

Actually, memory efficiency is generally higher for static executables.
The rtld needs to scribble in the text segment to do address fixups
so you lose most of the sharability gains.  Also, if you only have
one application using a shared library, you wind up paying for the
bloat of the complete .so, instead of just that bit that the application
actually uses.

>What about people who whine about recovery?

If you're doing bleeding-edge development (eg FreeBSD-CURRENT),
it's not that unheard pick a bad time to update and trash critical
bits of your system.

There are also security implications - with a dynamically linked
executable, there can be a long chain of assorted libraries that
you wind up executing - each of which need to be protected (along
with all their parent inodes).  I think I once counted >20 inodes
accessed for a dynamically linked "hello world" on Solaris.

Peter