Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.internals
Subject: Re: Shared Lib Question (ISC)
Keywords: ISC i386 shared libraries
Message-ID: <7894@auspex.auspex.com>
Date: 17 May 91 17:24:19 GMT
References: <169@titccy.cc.titech.ac.jp> <7762@auspex.auspex.com> <184@titccy.cc.titech.ac.jp>
Organization: Auspex Systems, Santa Clara
Lines: 48

>The problem is that NO OS support shared libraries right, perhaps because
>there is no way to do so.

Or, at least, you don't consider any OS to support shared libraries
right.  Others would disagree with you.

>>>Moreover, there seems to be no right implementation of shared libraries, so
>>>far.
>
>>OK, so what would you consider a "right" implementation of them?  
>
>Do you consider there is a "right" one?

Answer the question - and not with another question!  Do *you* consider
there to be a "right" one, or do you think that it's impossible to do
shared libraries "right"?  Given your statement:

>>>Moreover, there seems to be no right implementation of shared libraries, so
>>>far.

one might well reasonably conclude, from the "so far", that you believe
that it is possible.  If so, you obviously have *some* criterion for
deciding whether a shared library implementation is "right" or not; what
is that criterion?

>>What
>>don't you like about, say, Multics's implementation, or VMS's, or
>>Aegis's, or SunOS 4.x/S5R4's, or OSF/1's, or....?
>
>Indirect jumps and accompanied process private data for the jump table.

So if there were a shared library scheme wherein, say, each shared
library were placed at a fixed address in the virtual address space,
known somehow to the linker (perhaps it's in a header in the shared
library file), and the linker, when you link against a shared library,
turns a jump to some particular routine in that shared library into a
jump to the address that routine will have at run time, that might be a
"right" implementation?

Is your objection to the indirect jumps due to the extra CPU time spent
doing the jumps?  Some of us would probably be willing to pay the price
for those indirect jumps in exchange for the flexibility of being able
to plug in a new version of a shared library and still have old binaries
continue to run, just as some of us are willing to pay the performance
price for having software written in higher-level languages than
assembler in exchange for the flexibility of being able to move the
software to a different processor - others might not, but, hey, that's
what makes horse races.