Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!agate!darkstar!cats.ucsc.edu!jik
From: jik@cats.ucsc.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.programmer
Subject: Re: shared libraries, when to use them
Keywords: shared libraries .so
Message-ID: <17106@darkstar.ucsc.edu>
Date: 17 Jun 91 00:00:39 GMT
References: <1991Jun11.163544.20234@aio.jsc.nasa.gov>
Sender: usenet@darkstar.ucsc.edu
Organization: University of California, Santa Cruz
Lines: 70

In article <1991Jun11.163544.20234@aio.jsc.nasa.gov>, shirley@washington.jsc.nasa.gov (Bill Shirley) writes:
|> I was wondering when it's appropriate to use shared libraries? (specifically in SunOS)

(Please try to put linefeeds in your postings at least once every 80
characters.  The postings in news.announce.newusers discuss why this is
necessary.)

It seems to me that you are asking two different questions here.  First of
all, when is it appropriate to link an application static instead of linking
it dynamic and letting it used the installed shared library (the C library,
among others)?  Second, when is it appropriate, when building libraries of
your own, to use shared libraries?

There are three reasons you might have to link an application static, thus
bypassing the benefits of shared libraries: (1) The application is going to be
installed on the workstation root, and will need to be able to run even when
the filesystems with the shared libraries in them are not mounted, or are
inaccessible (e.g. you're using a diskless workstation and the network
suddenly goes down); (2) Startup time is very, very important, and you don't
want the applicatiom to suffer the slight delay in startup time that occurs
when the dynamic libraries are being linked; (3) Security concerns -- you're
using a relative link path to link against a library in a non-default
directory, and the program is going to be installed setuid or something.

If none of these are a problem for you, then there really isn't any resaon to
link static rather than dynamic.

Now, as to the question of when to build shared libraries of your own and when
to make them static.... In order to answer that well, you need to understand
the benefits that shared libraries provide; if your library will be used in an
environment that will take advantage of those benefits, then make it shared;
if not, the trouble of making it shared probably isn't worth the effort.  The
benefits include the ability to update the library without linking the
application (although some people consider that a flaw; please, I don't wan to
get into more religious wars about shared libraries here!), the fact that
dynamic binaries take up much less space on disk, and the fact that dynamic
programs take up less space in memory when there are several programs using
the same shared library routines.

|> Is it ever appropriate for non OS work?

What do you mean by "appropriate," and what do you mean by "non OS work?"

|> How exactly do you build it? (in SunOS)

There is extensive documentation in the SunOS manual sets about building
shared libraries.  Basically, you compile your object files with the -pic flag
to the compiler, and then use use ld with the flag "-assert pure-text" to put
all the object files into one file which is your shared library.  It is
installed with a ".so" suffix, and possibly a version suffix after that, in
order of the standard link directories, are accessed with a -L flag to the
linker.  It is not necessary to run ranlib over a shared library.

There are also some complications that might require you to also build a ".sa"
library to go along with your ".so" file, although I don't understand all the
details of all that (I've never had to do it), so you should look it up in the
Sun manuals.  Not doing it won't cause your libraries not to work, but will
cause some performance degradation in some situations.

|> When you compile something with a -Bstatic flag, where does it get its code from?
|> Does it extract the object part needed from the shared library (lib*.so.#[.#])?

I believe it extracts the code from the static libraries that are installed
for most libraries in addition to the shared libraries (e.g. libc.a has a
libc.a.so, which is shared, and a libc.a, which is not).  I'm not certain if
the linker is smart enough to use the position-independent code from the
shared library if a static library isn't installed.

-- 
Jonathan Kamens					jik@CATS.UCSC.EDU