Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!eagle!mhuxt!mhuxi!cbosgd!ihnp4!we13!burl!duke!unc!tim
From: tim@unc.UUCP
Newsgroups: net.unix-wizards
Subject: Re: another argument against shared libraries
Message-ID: <5691@unc.UUCP>
Date: Thu, 11-Aug-83 10:43:00 EDT
Article-I.D.: unc.5691
Posted: Thu Aug 11 10:43:00 1983
Date-Received: Fri, 12-Aug-83 17:40:04 EDT
References: orca.47
Lines: 23


    All the user-visible problems that have recently been mentioned
with respect to shared libraries, for instance programs breaking when
the library changes, are equally true of any library when the program
is relinked, which can reasonably be expected of any program in
general use or of medium or large size.  Given this, it is hard to
take these objections seriously.

    A much more serious objection is that the addition of a new
segment to each UNIX process, which seems to be the only clean way to
do this, involves far-reaching and non-trivial changes in the kernel.
I have yet to see anyone suggest solutions at this level; it's a
little early to start talking about flag bits in page tables, when we
don't even have an overall design for the thing.  This sort of
implementation-first thinking is just the thing that could cause the
kernel to be munged beyond hope, or more likely keep the project from
even getting off the ground.

___________
Tim Maroney
duke!unc!tim (USENET)
tim.unc@udel-relay (ARPA)
The University of North Carolina at Chapel Hill