Unfortunate dynamic linking for everything

[David Schultz]

On Tue, Nov 18, 2003, Robert Watson wrote:
> On systems like Mac OS X, use of a "shared
> region" permits not only use of prebinding, but assumptions of common load
> addresses for common libraries.  In addition, the "shared region" approach
> allows the reuse of page table and VM meta-data across many processes. 
> Leaving aside special-purpose optimizations like that, using some simple
> heuristics, we could probably easily reduce the number of load addressed
> dramatically, making prebinding a far more feasible approach, and
> something we should explore thoroughly.

IIRC, Dyson proposed something like that a while ago.  It's a neat
idea, particularly if it gets us away from PIC on register-starved
architectures such as the i386.

> John Dyson's suggestion of "mixed mode" linking, in which we statically
> link known required parts of binaries, but permit dynamic linking of
> "plug-in"  functionality is another quite reasonable solution, as long as
> we take care of the potential issue of "plug-ins" relying on symbols from
> a library that is statically linked to the application, but not in the set
> of symbols depended on by the application.

Wouldn't the first shared object you loaded instantly pull in
libc.so as a dependency, giving you pieces of both a static and a
dynamic libc?  It seems that that would break something...

> For big applications like KDE, Open Office, et al, prebinding probably is
> the right approach, and hopefully we have plenty of time before 5.3 to
> refine Matthew's work and see if we can't get things up to speed.

For these applications, the fork/exec overhead is so far into the
noise and there are so many shared libraries that dynamic linking
wins outright, prebinding or not.  Maybe for servers that fork a
lot this would be more contentious.