Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!cs.titech!titccy.cc.titech!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.unix.internals
Subject: Fundamental defect of the concept of shared libraries
Keywords: ISC i386 shared libraries
Message-ID: <197@titccy.cc.titech.ac.jp>
Date: 16 May 91 07:07:24 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>
Sender: news@titccy.cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 59

In article <1991May16.002617.15386@ladc.bull.com>
	fmayhar@hermes.ladc.bull.com writes:

>There may actually not be any "right" implementations extant at the
>moment (this is debatable), but that's not the point.

Without any fact, your claim is nothing.

Let's see what's wrong with shared libraries.

>-> Indirect jumps and accompanied process private data for the jump table.
>
>So what would be a better way to do it?
>
>Really, there's a tradeoff between the utility of shared libraries and
>efficiency.

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

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

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.

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.

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

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. As
a workaround, we can have two versoins of A.0: A.0.B.0 and A.0.B.1.
Thus, with the increase of number of kind of libraries, the number of
libraries and required storage grows exponentially.

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

The fundamental solution is, of course, not to have shared libraries.

						Masataka Ohta