Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!ns-mx!ns-mx.uiowa.edu!dbrenner From: dbrenner@sparta.weeg.uiowa.edu (Doug Brenner) Newsgroups: comp.sys.next Subject: Re: Library function redefinition Message-ID: Date: 4 Mar 91 18:40:44 GMT References: <1389@toaster.SFSU.EDU> <1396@toaster.SFSU.EDU> Sender: news@ns-mx.uiowa.edu Organization: U of Iowa, Iowa City, IA Lines: 20 In-reply-to: eps@toaster.SFSU.EDU's message of 4 Mar 91 09:06:55 GMT Well, I hope everyone has put this subject into their kill files by now. :-) In article <1396@toaster.SFSU.EDU> eps@toaster.SFSU.EDU (Eric P. Scott) writes: > What do you do about the case where procedures in the shared > library call other procedures in the shared library? Should > they continue to reference their shared library versions? > Or yours? If you opt for the former, you can no longer > statically link. If you opt for the latter, you can break > library routines that you _didn't_ redefine (what works in > one software release might not in the next if the library > changes, etc.). Strange, but I must again point to Prime shared libraries; they work just fine WITHOUT the endless problems you envision. (Certainly you already know this given your stated use of Prime systems.) I will not go through your notes, giving you solutions to every "horrific" problem you see looming should symbol redefinition be allowed. My point continues to be that there are valid implementations that address and resolve your questions. Prime is one; there is no reason NeXT should not be another.