Path: utzoo!attcan!uunet!mcsun!ukc!slxsys!olgba!olapw
From: olapw@olgb1.oliv.co.uk (Tony Walton)
Newsgroups: comp.unix.questions
Subject: Re: Shared libraries
Message-ID: <14307@olgb1.oliv.co.uk>
Date: 10 Jan 90 13:40:52 GMT
References: <941@targon.UUCP>
Organization: British Olivetti Ltd.,AT&T Division, London, England.
Lines: 57

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?

Well, I'll probably get flamed for oversimplifying this, but what the hell...

As you say, shared libraries aren't compiled into the executable, but reside
in one place only on the disk.  After the machine is booted, the first process
to require a shared library will cause the library to be loaded into memory
from disk; the library will remain loaded as long as at least one process 
requires it.  Any process which requires the shared library will use the copy
in memory rather re-loading the library from disk, if the library is already
loaded.

This means that

1) an executable linked to use shared libraries will (probably*) take up less
space on disk and in RAM  than one using archive (compiled-in) libraries and

2) will load slightly faster (because it's smaller).

3) changes, debugging, etc applied to the shared library will automatically
be applied to all executables which use the library without the need to
recompile each module. This also means that bugs introduced into the
shared library will automatically appear in all executables etc etc :-)

* Note the "probably" above there - if the executable uses very few library
functions and/or very small library functions, the overhead for the shared
library linkage may well be bigger than the library functions themselves,
making the executable bigger when linked to use shared libraries than when
linked standalone.

You can (on AT&T Unix, at least) create your own shared libraries quite simply -
basically you need to compile your functions as normal and create a table which
states where in virtual RAM the libraries are to be loaded.  Take care with this as
some areas are reserved for things like libc_s (the shared version of the
normal libc.a) and networking libraries (AT&T provide libnsl_s - Network
Support Library which includes the TLI functions).  Other areas are reserved
for graphics libraries, statistics libraries, etc.  The AT&T Programmer's Guide
has quite a large section on shared libraries, how to create them, when not
to use them, and so on.

The problems mentioned above regarding address overlap apply to *statically* linked
shared libraries only - *dynamically* linked shared libraries will be avialable
under Unix System V rel 4.0; they are based on the SunOS 4.0 implementation
and remove the requirement to bind libraries to fixed pathnames and fixed
virtual addresses.

-- 
Tony Walton, OEM/VAR Division, British Olivetti Ltd., 154-160 Upper Richmond Rd,
LONDON, SW15 2FN.  Tel: (+44) 1 789 6699 Telefax: (+44) 1 785 6670 Telex:27258
Uucp : { ukc!uel | mcvax!olnl1 | ihnp4!cuuxb | iconet | olhqma } !olgb1!olapw
olapw@olgb1.oliv.co.uk