Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.programmer
Subject: Re: shared libraries, when to use them
Keywords: shared libraries .so
Message-ID: <8505@auspex.auspex.com>
Date: 24 Jun 91 17:29:40 GMT
References: <1991Jun18.050150.17149@thunder.mcrcim.mcgill.edu> <8448@auspex.auspex.com> <1991Jun21.155441.1689@thyme.jpl.nasa.gov>
Organization: Auspex Systems, Santa Clara
Lines: 34

>So, if I understand SunOS and its shared libraries (and it's possible
>I don't.)  The shared libraries are created with the link editor, and
>one monolithic binary "library" is created.

True.

>Later, at run-time, if a reference to one symbol in a SunOS shared
>library causes the whole image to be loaded into memory (unused
>sections may be paged out later)

Unless somebody screwed up in making the library, that does *not*
happen.  The entire image is mapped into the virtual address space of
the process, but the pages of that image are pulled into physical memory
only on demand; unless the run-time loader has to relocate something on
every page (if it does, as indicated, somebody screwed up), not every
page gets pulled in.

>Two questions come to mind, one easy, one hard:
>
>How do SV.[34] shared libraries differ from SunOS shared libraries?

The first question to ask might be "How do SV.3 shared libraries differ
from SV.4 shared libraries?"

SV.3 shared libraries are allocated a fixed location in virtual address
space when they're built, and you have to go through some effort to
modify the source of the library routines to make them work.

SV.4 shared libraries are derived from SunOS 4.x shared libraries; they,
like SunOS 4.x shared libraries, are normally built in
position-independent form and don't always have to be at the same place
in the virtual address space; the changes made to the source of library
routines for SV.3 shared libraries aren't done for SV.4 shared libraries
(you may still want to make some changes for performance reasons).