Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!cs.mu.OZ.AU!kre From: kre@cs.mu.oz.au (Robert Elz) Newsgroups: comp.unix.internals Subject: Re: Shared libraries Message-ID: Date: 4 May 91 05:45:35 GMT References: <1991Apr24.231048.2987@Think.COM> <148@titccy.cc.titech.ac.jp> <19239@rpp386.cactus.org> <1991Apr29.031351.3912@decuac.dec.com> Sender: news@cs.mu.oz.au Lines: 28 mjr@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