Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.programmer
Subject: Re: shared libraries, when to use them
Keywords: shared libraries .so
Message-ID: <1991Jun22.163706.1174@thunder.mcrcim.mcgill.edu>
Date: 22 Jun 91 16:37:06 GMT
References: <1991Jun11.163544.20234@aio.jsc.nasa.gov> <8448@auspex.auspex.com>
Organization: McGill Research Centre for Intelligent Machines
Lines: 56

In article <8448@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes:
[Guy apparently deleted, or failed to insert, an attribution header;
the missing attribution is to me. -dM]
>> You can't, because SunOS doesn't have shared libraries.  (What it
>> does have is shared object files.  What's the difference?  You can
>> link in part of a library without linking in the rest, among other
>> things.)
> Just out of curiosity, who *has* implemented shared libraries?

It's been several years since I used it, but I *think* VMS did.  I
don't remember precisely, though.

Actually, this is a good opportunity: I got mail from someone who
pointed out that one can consider a Sun .so file as a "library", which
is true but uninteresting, because one can actually consider any
collection of code as a library: a directory with .o files in it, a tar
archive of .c and .f files, a shar of .s files....  I was using
"library" as something like a technical term.

Which brings up the next question: "fine, but what's your point?".

The main point is that the semantics are different.  A "library", in
the past, is something from which "modules" are extracted and included
in the program as necessary.  No more than necessary is included from
the library.  But the thing so often termed a "shared library" has
different semantics.  While for the most part the difference is not
visible, it is in one case: when a routine in the user program has the
same name as a routine in the library.  This is generally bad
programming practice, when done deliberately - but when linking with a
"shared library", there's often no notification that there's anything
wrong; the program just does mysterious things, and worse, the symptoms
go away or change when linked -Bstatic.

(There are other differences; for example, the SunOS core-dump routine
has a bug in that the core files it generates don't include anything
from any dynamically linked shared objects.)

SunOS could be made to do shared libraries instead of shared objects,
without all that much work.  All that would be necessary would be to
have ld.so map the .a file instead and do the relevant relocations,
which it has to be prepared to do anyway.  Differences I see: (1) this
would almost surely be slower than the current scheme; (2) there's less
memory sharing at run-time, because more of the mmap()ed memory would
have to be modified by relocation; (3) only one library to maintain
instead of two, and the semantics are the same.

(In passing: anyone know why Sun doesn't document the format of the
ld-generated data structures?  There are things I'd like to do for
which I require that information, and <link.h> doesn't have all of it.
Please don't tell me I have to uncompile ld.so to figure this out....)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu