Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!usc!samsung!uakari.primate.wisc.edu!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.questions
Subject: Re: Shared libraries
Message-ID: <11915@smoke.BRL.MIL>
Date: 8 Jan 90 22:48:24 GMT
References: <941@targon.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23

In article <941@targon.UUCP> ruud@targon.UUCP (Ruud Harmsen) writes:
>What exactly are shared libraries?  What UNICes have them?  Does it mean that
>frequently used libraries are no longer compiled into the executable, but
>reside only in the library?  Does this save space on disk, or also at
>runtime, in core?  Can you do it only with standard libraries, or also with
>your own?  Is it any slower or faster than the normal way?

You seem to have the right notion already.  Shared libraries are pretty
much standard on UNIX System V Release 3 and later, as well as on some
UNIX-based systems for small (PC-like) environments.  Space is definitely
saved on disk and in general main memory demand is also reduced.  Users
can generally create their own shared libraries, but you need to work
hard at doing it right, since the initial interfaces cannot be changed
later without recompiling EVERY application that used the shared library.

There is a very slight added cost in calling a shared library function,
but it is almost always repaid by the overall reduced load on the system.

One implementation technique is for there to be a vector of standard
(shared) function pointers in a segment that is mapped at execution
time into the same virtual space as the shared library implementation's
vectors.  Because the vectors are always at the same address, the library
can be improved without requiring that existingt applications be relinked.