Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!uwm.edu!linac!mp.cs.niu.edu!rickert From: rickert@mp.cs.niu.edu (Neil Rickert) Newsgroups: comp.unix.internals Subject: Re: Shared libraries Message-ID: <1991May4.132632.13885@mp.cs.niu.edu> Date: 4 May 91 13:26:32 GMT References: <19239@rpp386.cactus.org> <1991Apr29.031351.3912@decuac.dec.com> Organization: Northern Illinois University Lines: 21 In article kre@cs.mu.oz.au (Robert Elz) writes: >and even more importantly, the ability to make changes to library >routines that affect all processes to use the library after the change, >without recompilation or re linking (other than normal shared library >runtime linking). You have just listed as a benefit of shared libraries that feature which can cause perfectly good working programs to suddenly be broken just because someone changed the shared libraries. I consider that to be a major disadvantage of shared libraries. On the other hand, I understand your point. It allows you to take old code using the hosts tables, and have it suddenly use the nameserver, for example. But a module structure which allowed re-editing a binary, and explicitely replacing one module in it, would give a much more useful level of control. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940