Shared libraries

[Robert Elz]

mjr at hussar.dco.dec.com (Marcus J. Ranum) writes:

>	I somewhat disagree. The trick is to take a step back - forget
>the bloody shared libraries and develop a system with a decent virtual
>memory system that allows nice shared memory, memory mapping, and copy
>on write type semantics for those pesky data areas, and shared libraries
>are less of a problem.

This seems to assume that you want shared libraries to same memory (VM),
which of all the benefits is the least I care about.  More important
is to save disc space for the binaries (I only run a few of them at a
time, but I want thousands around for when I may want to run them),
and even more importantly, the ability to make changes to library
routines that affect all processes to use the library after the change,
without recompilation or re linking (other than normal shared library
runtime linking).

The trick is to make that work so shared library routines can call routines
defined in the application - replacing a routine in the library, just as
they would if the library wasn't shared, and so the shared library can have
shared initialised data that can be referenced and modified (obviously copy
on write) by the application, without the compiler being aware that the data
to be referenced is in a shared area (hence, has no fixed address) when the
object file is compiled.

And next make it work so that the whole thing doesn't run like a camel...

kre