Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!pa.dec.com!wsl.dec.com!mcnally
From: mcnally@wsl.dec.com (Mike McNally)
Newsgroups: comp.unix.internals
Subject: Re: Fundamental defect of the concept of shared libraries
Keywords: ISC i386 shared libraries
Message-ID: <1991May16.135931@wsl.dec.com>
Date: 16 May 91 20:59:31 GMT
References: <162@titccy.cc.titech.ac.jp> <7690@auspex.auspex.com> <169@titccy.cc.titech.ac.jp> <7762@auspex.auspex.com> <184@titccy.cc.titech.ac.jp> <1991May16.002617.15386@ladc.bull.com> <197@titccy.cc.titech.ac.jp>
Sender: news@pa.dec.com (News)
Reply-To: mcnally@wsl.dec.com
Organization: DEC Western Software Lab
Lines: 75

In article <197@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
|> Effeciency is only one aspect of the problem.
|> 
|> To share libraries, they should be:
|> 
|> 	1) coded position independently (PIC)
|> 
|> or
|> 
|> 	2) assigne static virtual address
|> 
|> If we take 1), the hardware architecture must support PC relative jump,
|> of course.

No No No No No No No.  All that's needed is indirect jump.  Pull your head 
out before being so dogmatic.

|> Moreover, to access library private data, it must also
|> address data PC relative. Aside from effeciency, not all architechture
|> support this.

Once again, indirection is all that's needed.

|> Note that, library private data is inevitable to support calls between
|> libraries, position independently.

So?

|> Even worse, with some architechture, it is impossible to map several virtual
|> addresses to a physical address. Virtually tagged cache and inverted
|> page tables are notable examples.

OK fine.  Maybe we shouldn't have inter-process memory protection since not
all architectures support it.  Hell, better dump floating-point too, since my
8085 machine at home doesn't have it.

|> 
|> If we take 2), even if you have enough address space to map all libraries
|> (32 bits is obviously not enough, I even think 48 bits is not), it will
|> be nightmare to maintain consictency. Different libraries must
|> have different addresses, of course, which is already non-trivial.

Gee, Masataka, maybe you should re-state your argument:

	"*I* don't know how to solve the problems of shared libraries
	to *my own* satisfaction based on *my own* dogmatic criteria,
	and so *I* won't implement shared libraries, nor will I touch
	any system which uses them."

Sheesh.

|> 
|> Moreover, compatible libraries must have the same address, whose scheme
|> will be very complex, even though it exists.

What does this mean?

|> 
|> Even worse, if a program is linked with libraries A.0 and B.0 and the
|> other program is linked with libraries A.0 and B.1 (an upgraded version
|> of B.0) and a function in A.0 calls a funtion in B.*, it can't.

Why not?  Granted, both versions of B will have to be loaded, but "can't"?
I ask you to "prove" that; please try to be a bit more rigorous when giving
proofs, too.  It's not enough to say "I propose P, I proved P, QED."

|> I hope you can now understand how complex the shared library is.

I now understand that you don't know how to implement shared libraries.

-- 
* "In the Spirit as my automatics,  *                              Mike McNally
* Lystra and Zelda were one third   *                                    Coolie
* as large as the infinite Cosmos." *                  DEC Western Software Lab
*              --- D. S. Ashwander  *                       mcnally@wsl.dec.com