Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!uwm.edu!uwvax!margay.cs.wisc.edu!dws
From: dws@margay.cs.wisc.edu (DaviD W. Sanderson)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Libraries: Unique to Suns??
Message-ID: <1991Mar26.174156.3816@spool.cs.wisc.edu>
Date: 26 Mar 91 17:41:56 GMT
References: <1991Mar24.152800.20651@cbnewsm.att.com> <1991Mar25.035710.27456@spool.cs.wisc.edu> <29682@cs.yale.edu>
Sender: news@spool.cs.wisc.edu (The News)
Organization: U of Wisconsin CS Dept
Lines: 45

In article <29682@cs.yale.edu> yarvin-norman@cs.yale.edu (Norman Yarvin) writes:
>dws@margay.cs.wisc.edu (DaviD W. Sanderson) writes:
>>  The BIG disadvantage relative to dynamic shared libraries
>>is that source code maintenance is a headache if you want to create
>>a new version of the library that can be installed and used by
>>programs already linked with an older version of the library.
>
>The Unix PC ameliorates this difficulty using stub routines.  The address to
>which a call to a shared library function is linked is the address of a jump
>statement which jumps to the real function.  All these jump statements are
>grouped together at the start of the shared library.  Thus programs compiled
>under any version of the Unix PC shared library run under any other version.

Yes, it is relatively easy to deal with functions in static shared
libraries.  However, persistent data is a different story.  There is no
(supported) equivalent concept of a "junk table" allowing an
indirection in access to data (that is transparent to the source
code).  You have to guarantee that your new data structures sit at the
same place in memory and have the *same size* as in the earlier
versions of the library.  One concrete example where this comes up is
upgrading the stdio part of libc (or any other part that uses
persistent data).  It was a real pain (so I heard, I didn't do it) to
upgrade the shared libc to handle multibyte characters (and thus
multibyte pushback) for ANSI C support, because the composition of the
existing _iob[] array could not be changed.

In order to make the guarantees about the external data you have to
separate out all the declarations of *any* persistent data into source
files separate from where the functions are defined, so that you can
group the corresponding object files at the beginning of the static
shared library.  Then whenever you add new persistent data you add the
corresponding object file onto the end of the existing data object
files.  You cannot alter the composition of the preexisting persistent
data without risking breaking compatibility with older versions of the
library.

Dynamic shared libraries impose none of these silly source code
conventions.
-- 
       ___
      / __\  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)