Newsgroups: comp.unix.internals
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Subject: Re: Shared libraries
Message-ID: <1991Apr24.231048.2987@Think.COM>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <136@titccy.cc.titech.ac.jp> <718@seqp4.UUCP>
Date: Wed, 24 Apr 91 23:10:48 GMT

In article <718@seqp4.UUCP> jdarcy@seqp4.ORG (Jeff d'Arcy) writes:
>  Do you really think so many skilled and knowledgeable
>OS developers would implement shared libraries if they weren't worth it?

What I want to know is why it has taken so long for them to rediscover
shared libraries.  Multics, the predecessor to Unix, was using
dynamically-linked, shared libraries in the 60's.

Furthermore, the SunOS dynamic linking design is still inferior to the
Multics design (I don't know details of other Unix dynamic linking
designs).  Libraries should be linked on demand, not all at the beginning
of the program.  This way, infrequently-used routines do not have any
overhead except when they're used.  However, this should be coupled with
better OS support for dynamic link failures (it would be a shame for the
process to core dump just because LD_LIBRARY_PATH is missing a necessary
directory).  Also, on-demand linking is harder to implement for data than
for code, often requiring hardware support (Multics does all dynamic
linking by indirecting through pointers with a special trap bit set -- the
trap handler resolves the link, rewrites the pointer, and restarts the
interrupted instruction, so procedures and data are equivalent).

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar