-------------------------------------------------------------------------------
Create a Shared library from C functions

     gcc -fPIC -shared -o b.so  b.c

The -FPIC tells the compiler to make the code "position independant".
The -shared is for the linker not the compiler, to generate a dynamic library
instead of an executable.

-------------------------------------------------------------------------------
Override Libraries

See examples in personal area "~/store/c/override_libraries/"

This is used to modify the action of various library calls
allowing you to do things either before, or afetr the call to
the real library function (if you call it at all)

For example
  * make an open of 'this' file actually opens 'that' file.
  * redirect a network port to a pre-opened privileged port
  * insert a monitor of a file stream to log 'writes' or 'reads'

A program that does this is "tsocks" whcih is a wrapper around programs
to re-direct all its network connections to a socks proxy.
   http://tsocks.sourceforge.net/about.php

You may also like to look at
   http://www.semicomplete.com/projects/liboverride

-------------------------------------------------------------------------------

From: jik@cats.ucsc.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.programmer
Subject: Re: shared libraries, when to use them

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. The LD_LIBRARY_PATH environment
variable is the cause of this security hole.
  (4) If you need to support multiple versions of an OS and don't want
to have to worry about what version of the shared libraries your users
have.
  (5) If you wish to use a tool like undump, that depends on useful
core files, because there's a bug in Sun's dump-core routine that
causes dynamically linked object files' data areas to be omitted from
core dumps.

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.

|> 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.

-- 
Jonathan Kamens					jik@CATS.UCSC.EDU

-----------------------------------------------------------------------
Presumably you would like to know what's in the Makefile, then :-)

Here, for example, is the Makefile from one directory in which I have
source that gets compiled and put into a shared "library":

.c.o:
	$(CC) $(CFLAGS) -pic -c $<
	mv $*.o $*.so
	$(CC) $(CFLAGS) -c $<
install:
	cp *.o o-files/unshared
	cp *.so o-files/shared
	( cd o-files ; make $(MFLAGS) install )

And then o-files/Makefile:

install:
	( cd unshared ; make $(MFLAGS) install )
	( cd shared ; make $(MFLAGS) install )

and o-files/shared/Makefile (o-files/unshared/Makefile is an
uninteresting exercise in the user of ar):

install:
	-@ rm -f lib.so
	-@ ( ls -1 *.so |sed -e 's/\(.*\).so$$/mv \1.so \1.o/' ) 2>/dev/null | sh -v
	ld -assert pure-text -o lib.so *.o
	cp lib.so /the/installed/version/of/lib.so.1.5

					der Mouse

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

-----------------------------------------------------------------------
Security for shared libraries

   A dynamically linked SUID program can create a security hole through
the use of shared (dynamic) libraries. The problem is that environment
variables that control the use of SunOS shared libraries (see
comp.security.announce for the relevant CERT advisory).

   Environment variable sanitizer -- see 
                                 --- Wietse Venema <wietse@wzv.win.tue.nl>

   The fact of the matter is that there are only a handful of environment
variables that can really affect security, and only these need to be
censored.  The LD_ variables are particularly insidious because they are
used before the program they affect has a chance to do anything about it.
                                 --- Barry Margolin <barmar@think.com>

-----------------------------------------------------------------------