Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!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 07:47:52 GMT References: <1991Mar1.143756.12400@usenet.ins.cwru.edu> <1383@toaster.SFSU.EDU> <1389@toaster.SFSU.EDU> Sender: news@ns-mx.uiowa.edu Organization: U of Iowa, Iowa City, IA Lines: 23 In-reply-to: eps@toaster.SFSU.EDU's message of 4 Mar 91 03:14:01 GMT In article <1389@toaster.SFSU.EDU> eps@toaster.SFSU.EDU (Eric P. Scott) writes: > We still have a Prime 9955-II running PRIMOS that I still use on > occasion. Pay up. Given your experience with Prime shared libraries, I find it difficult to understand (what appears to be) your support for how NeXT has chosen to implement shared libraries. Since the release of 2.0, you have lambasted people at least three times when they have mentioned this shared library problem. Each time trying to defend this "feature" (as you now call it) by pointing out that SunOS and System V have the same problem. (This is, of course, how I understood your notes. :-) In my note, I simply wanted to offer a counter example -- an implementation that doesn't have this shared library problem. It is my opinion that the current NeXT implementation of shared libraries leaves much to be desired. The restrictions are unnecessary; there are implementations (Primos being one) that show this. I hope NeXT will choose to consider this a problem; one that they will address in the future. (And I don't mean by simply giving us a static library to bind to instead.)