Fundamental defect of the concept of shared libraries

[Jeremy Fitzhardinge]

mohta at necom830.cc.titech.ac.jp (Masataka Ohta) writes:

>In article <1991May16.002617.15386 at ladc.bull.com>
>	fmayhar at 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 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.

Why not relocate a library into a virtual address when it is loaded, so
that you dont need to assign an address when the library is made.  It
is quite compact and efficent to store relocation information and apply
it as you load.  An executable could use some key to tell the OS what
library it needs and the OS returns the virtual address of a library,
either just loaded or loaded for something else.  The program can
then relocate its library calls to the address.  The library could
either use a jump table or have real symbolic information (which is
nicer, I think).

>I hope you can now understand how complex the shared library is.
>
>The fundamental solution is, of course, not to have shared libraries.

Multitasking gets pretty complex too - is it worth the effort?

--
jeremy at softway.sw.oz.au ph:+61 2 698 2322-x122 fax:+61 2 699 9174
"Hi Barbie, I'm your plastique surgeon, Roger.  Are you ready for your
 Semtex augmentation?"... "John Thompson died for you" society meets now.
I opine for the fjords, nothing else.