From: drew@ophelia.cs.colorado.edu (Drew Eckhardt)
Subject: Re: GCC2.1 (Wonderful !)
Keywords: gcc, 2.1, 1.40
Organization: University of Colorado at Boulder
Date: Thu, 16 Apr 1992 10:22:20 GMT

In article <1992Apr15.151509@hammer.Prime.COM> cummings@hammer.Prime.COM (Kevin Cummings) writes:
>OK, coming from one of the companies that pioneered shared libraries
>for the mini-computer industry, and therefore having a VERY one-sided
>view of them, I need to get a few questions answered about LINUX
>shared libraries.  So here goes:
>
>    Are the shared libraries dynamicly linked to at runtime?  or are
>    the .a files bound at install time to whatever shared library
>    is in /lib/whatever?  If the latter, then this would explain the

Not at this time.  It would be pretty easy to fix though, if not 
a bit kludgy...
  
Attention fellow kernel hackers, and aspiring kernel hackers to be : 

Implementing dynamically linked shared libraries :
	A simple kludge.

(we definately want this so we CAN distribute everything in a shared form)

1.  There should be a temporary directory for keeping a linked 
	version of something compiled with shared libraries.
	Linking to a binary on disk allows us to keep the 
	existing mm routines that do demmand paging, and 
	sharing of pages between different copies of 
	the same program.

	This temporary directory would be set with a 
	syscall.  A user program, such as swapon,
	would be created to interface this, and 
	could be run from /etc/rc.

2.  When exec() is called, it checks for #!, and the a.out
	magic numbers.  We add a new magic number, saying 
	"This is a dynamically linked program."  If exec()
	encounters this magic number, it checks to see if 
	an already linked version of the program exists
	in the temp directory, and execs that if it does.

	Naming of the already linked version should be unique 
	across all file systems, probably combining inode #
	and dev # from which the file system is mounted.

	If this does not exist, then exec() execs /bin/ld.
	The shared version has been linked to everything but
	the shared library stubs.  It is now linked to
	shared library stubs stored in /lib/libstubs.a.  

	Note that crt0.s will have to change to use 
	/lib/greatest or whatever, instead of 
	the dated version number necessary with statically 
	linked shared libraries.

3.  exit(2) is modified so that when reference count reaches 0
	of that program, the linked version is unlink(2)'d from
	the temporary directory.

	
Advantages of this method :
1.  We don't introduce the bloat of ld(1) in the kernel.

2.  The existing mm code that handles page sharing, and demand
	loading continues to work.

3.  We still don't swap text to swap space.

4.  We get the adantages of dynamic linking, and can 
	safely distribute code that uses shared libraries.
   
Disadvantages :
1.  Execing /bin/ld is a BIG kludge.  

2.  We use disk space for the linked version + disk space for
	the unlinked version
			
	
>    "extra" step necessary to "install" the programs that use them
>    and why .a files are necessary.  Does this mean that these 
>    programs that use shared libraries must be re-installed every time
>    the shared library is updated?  (If so, then: Barf, puke, etc.)

You *CAN* keep an old version of the shared library binary around.
Otherwise yes.

>


(Barf, Puke, etc) : Agreed.  See above Super-{hack,Kludge} depending
on your perspective to rectify this situation.  If no one else does 
it, I might do it myself...