Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!mailrus!umix!uunet!mcvax!botter!star!jos From: jos@cs.vu.nl (Jos Warmer) Newsgroups: comp.software-eng Subject: Re: Question Re: Configuration Management Message-ID: <667@kajak.cs.vu.nl> Date: 8 Mar 88 11:51:16 GMT References: <497@aimt.UUCP> <5257@well.UUCP> <2984@metavax.UUCP> <2985@metavax.UUCP> <34359UH2@PSUVM> Reply-To: jos@cs.vu.nl (Jos Warmer) Organization: VU Informatica, Amsterdam Lines: 39 In article <34359UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: >How does this "smart linker" business tie into the "shared libraries" >in Unix V.3. As I understand it, (1) when I need a module, the whole >library is loaded, but (2) when another program needs a module from >the library, it shares the core image that is already in memory. > >So, for example, at any moment, there is only one copy of all the stdio >(that's standard input-output in Unix-speak) stuff in memory at any given >moment, and all programs that need it share. (This also makes the >executables smaller and saves disk space and load time.) > > Just asking, Lee Shared libraries do have the advantage of making the executables smaller. There is however also a disadvantage which we stumbled across last week. We have a program installed under VMS at a client of us. The program was tested and worked perfectly well for several months. Then all of a sudden it started to produce erroneous output, and we got an alarming telephone call. What happened ? The day things went wrong, they had a new version of the VMS C compiler installed, including of course the (shared) libraries. The errors in the unchanged working program emerged from an error in the new libraries. Moral: Replacing shared libraries with new versions could make lots of working programs crash. Because those libraries are instantaneously used in almost ALL running programs, one error in such a library can be fatal for the complete system. Jos Warmer, VU Informatica Amsterdam jos@cs.vu.nl