Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!philmtl!philabs!gotham!east!diag2!gsteckel
From: gsteckel@diag2.East.Sun.COM (Geoff Steckel - Sun BOS Software)
Newsgroups: comp.unix.xenix
Subject: Re: Using GCC/GAS Xenix on AT&T Unix V/386.3.2 (shared libraries0
Summary: the linker does have to set up shared libraries
Keywords: code-sharing
Message-ID: <1821@east.East.Sun.COM>
Date: 30 Apr 90 20:51:42 GMT
References: <2459@crash.cts.com> <3281@auspex.auspex.com>
Sender: news@east.East.Sun.COM
Reply-To: gsteckel@diag2.East.Sun.COM (Geoff Steckel - Sun BOS Software)
Organization: Sun Microsystems, Billerica MA
Lines: 40

>>Maybe I am as well.  My understanding is that the linker has to link up the
>>code in such a way that it can be swapped or demand paged.

Not quite, but close.  The choice is between an executable with all its
code, including the library routines, in the file, or an executable which
attaches to a shared library at run time.  In both cases the OS pages, swaps,
or whatver it feels like.

The motivation is that sharing one copy of the standard libraries takes much
less space in memory and on disk than separate library pieces in each program.
The cost is some extra setup.

The linker must either link in the correct library
routines, or a set of stubs which correspond to the `well known' entry points
in the shared library segment.  I don't know exactly how SysV/386 handles
this, but the stubs are either just absolute addresses or jumps to absolute
addresses (perhaps via indirection, like through a table).

At run time (again I don't know exactly how SysV/386 works, but some wizard
can enlighten us) one of three things happens:
  1) The executable is marked `uses shared library' and the OS automatically
     maps it in.
  2) Part of the standard startup (like /lib/crt0.o) contains a system call
     to map in the appropriate library.
  3) The first call to the library page faults, but the OS recognizes the
     address range and maps in the shared library.

At a guess, #2 is what happens.  Usually a code is stored by the linker in
the executable to declare what version of the library the executable was
linked against.  Most systems check this code (either in the application or
in the OS) at process startup and exit with an error if the program is being
run with a library version older than the one which was used for linking.

Whew.  I hope this clarifies things a little.  Any more exact information
gratefully appreciated.

	geoff steckel (gwes@wjh12.harvard.EDU)
			(...!husc6!wjh12!omnivor!gws)
Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line.
This posting is entirely the author's responsibility.