shared libraries, when to use them

[der Mouse]

In article <17106 at darkstar.ucsc.edu>, jik at cats.ucsc.edu (Jonathan I. Kamens) writes:
>> [stuff about SunOS 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);

Uh, if the network goes down on a diskless you generally can't even get
your executable off disk to run it at all.

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

To which I would like to add

(4) The executable needs to be able to survive being run with
    LD_LIBRARY_PATH set such that ld.so would pick up an incompatible
    version of some library.  (MIT X versus "Open"Windows X has
    produced such a situation in my experience.)

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

(While I'm here: WHEN WHEN WHEN will Sun provide a tool to turn a
dynamically linked executable into a statically linked one, or (even
better) document the format of the magic ld-generated stuff so we can
write our own?!)

					der Mouse

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