Path: utzoo!attcan!uunet!samsung!usc!apple!abyss
From: abyss@Apple.COM (Ananthan Srinivasan)
Newsgroups: comp.unix.aux
Subject: Re: Shared libraries
Keywords: Have they been used widely? How to compile with them?
Message-ID: <43923@apple.Apple.COM>
Date: 13 Aug 90 20:28:22 GMT
References: <2631@sequent.cs.qmw.ac.uk>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 25


The shared library implementation of libc need not (and does not for A/UX 2.0)
mean that the entire libc is shared. Only the routines within libc that are
used frequently are combined to form the sharable part of libc. The rest of the
routines are not shared. Another of the considerations to get the best out of
shared library implementation is to keep files with large 'data' spaces out of
the shared library - as 'data' is not shared. As a result, both perror and
get-myaddress are not included in the sharable portion of libc. (perror uses
the standard error strings which are not part of the sharable portion of libc
because of its big contribution to the 'data' space - similarly all the routines
in libc which use perror/the standard error strings have been left out of the
sharable portion.)
Sure if our compiler makes all the string constants part of the 'text' space,
it could be used to get more savings and I will pass that info. on to our
compiler experts.
[As an aside: Even if the string constants were made part of the 'text' space,
it is not obvious that 'error-related-routines' would be made sharable. In most
cases they probably result in smaller executables, but then the 'text' portion
of the shared library which is around in main memory has stuff which is used
only in case of an error and thus programs/daemons/etc. which are used very
frequently (if not all time) may end using main memory inefficiently.]
Shared libraries are linked just like any other standard libraries (use '-lfoo'
with ld to use the shared library /lib/libfoo assuming that the corresponding
target portion of the library is in the /shlib directory).
Srinivasan, A.B.