Xref: utzoo comp.unix.wizards:24528 comp.sys.3b1:884
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!yale!quasi-eli!cs.yale.edu!yarvin-norman
From: yarvin-norman@cs.yale.edu (Norman Yarvin)
Newsgroups: comp.unix.wizards,comp.sys.3b1
Subject: Re: Shared Libraries: Unique to Suns??
Message-ID: <29682@cs.yale.edu>
Date: 25 Mar 91 23:24:29 GMT
References: <1991Mar24.024830.8763@swbatl.sbc.com> <1991Mar24.152800.20651@cbnewsm.att.com> <1991Mar25.035710.27456@spool.cs.wisc.edu>
Sender: news@cs.yale.edu
Followup-To: comp.unix.wizards
Lines: 21
Nntp-Posting-Host: turquoise.systemsx.cs.yale.edu
Originator: yarvin@turquoise.CS.Yale.Edu

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.

Clearly this makes things slightly slower.  Also, it still isn't as easy to
add new functions to the shared library; for programs that use new shared
library functions to be portable between two machines, entries must have
been added to the jump table in exactly the same places.

--
Norman Yarvin					yarvin-norman@cs.yale.edu
 "Praise the humanities, my boy.  That'll make them think you're broadminded!"
	-- Winston Churchill