Xref: utzoo comp.unix.wizards:24529 comp.sys.3b1:886
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!uwvax!margay.cs.wisc.edu!dws
From: dws@margay.cs.wisc.edu (DaviD W. Sanderson)
Newsgroups: comp.unix.wizards,comp.sys.3b1
Subject: Re: Shared Libraries: Unique to Suns??
Message-ID: <1991Mar25.231421.15496@spool.cs.wisc.edu>
Date: 25 Mar 91 23:14:21 GMT
References: <1991Mar24.152800.20651@cbnewsm.att.com> <1991Mar25.035710.27456@spool.cs.wisc.edu> <CEDMAN.91Mar24215129@lynx.ps.uci.edu>
Sender: news@spool.cs.wisc.edu (The News)
Organization: U of Wisconsin CS Dept
Lines: 52

cedman@golem.ps.uci.edu (Carl Edman) writes:
>You did not mention one of the greatest advantages of shared libraries
>, IMHO:
>
>3. Library bugs can be fixed ...
>         without requiring recompilation.

Yes, this is certainly a property of shared libraries, both static and
dynamic.  However it can be tricky to do, since a program may depend on
a bug in the library.  Validating that the new library won't break old
programs is a hard problem.  The same problem exists with ordinary
archive libraries, but at least installing a new archive library won't
break existing programs linked with an older archive library.

My impression is that this property is only periperally an advantage,
and mostly a cost, when using static shared libraries.  This is because
of the difficulties I have already alluded to in creating new, backward
compatible static shared libraries.  This is not as much of a problem
in dynamic shared libraries.

>3.                           and even the functionality of a program
>extended without requiring recompilation.

A program using static shared libraries can't do anything more than if
it weren't using static shared libraries.  It just starts faster.  So
the ability to extend the functionality is limited to what you could do
with archive libraries.  Of course, if you had your main processing
loop as a library function, then you could arbitrarily change what your
program did by changing the library.  But I don't think this is a
typical use.

On the other hand, the ability to truly extend the functionality of a
program in certain ways without recompilation is entirely within the
capabilities of dynamic shared libraries.  For instance, a graphics
program could have an abstract plotter interface.  When the program was
about to produce output, it would determine which plotter driver it
needed to use, dynamically link it in, use it, and then unlink it.
Support for new output devices could be added without recompiling the
program.

It would certainly be possible to get this particular functionality
with separate, specialized i/o programs for each output device, using
some sort of communication protocol (temp file, IPC, whatever) with the
main program.  But it would (I think) be harder to do than simply
writing a set of subroutines.
-- 
       ___
      / __\  U N S H I N E	           DaviD W. Sanderson
     |  |  | I N E			    dws@cs.wisc.edu
_____|  |  |_____  ________
\      / \   |__/ /////__	Fusion Powered Locomotives Made to Order
 \____/   \__|_/  \\\\\______	 (TARDIS model available at extra cost)