Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!mp.cs.niu.edu!bennett From: bennett@mp.cs.niu.edu (Scott Bennett) Newsgroups: comp.sys.next Subject: Re: Library function redefinition Message-ID: <1991Mar4.234345.3913@mp.cs.niu.edu> Date: 4 Mar 91 23:43:45 GMT References: <1396@toaster.SFSU.EDU> Organization: Northern Illinois University Lines: 63 In article dbrenner@sparta.weeg.uiowa.edu (Doug Brenner) writes: >Well, I hope everyone has put this subject into their kill files by now. :-) Not yet, but probably shortly. ;-) > >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. (IBM bashers please hold your fire a moment. Thank you.) What all the discussion in this thread is pointing to is the woeful inadequacy of the UNIX ld(1) program. More than 25 years ago IBM had a much more flexible and powerful linkage editor (in several sizes) for OS/360 that completely bypassed not only Doug's problems with ld(1), but quite a few others as well. The descendent of the OS/360 linkage editor survives today in MVS with relatively few changes in features because IBM had given it enough flexibility at the outset that not much else has been needed. It would be nice if someone (e.g. FSF) would develop a replacement for (or at least an alternative to) ld(1) that would get rid of the need for so many of the contortions I see developers going through to get around ld(1)'s inadequacies. The OS and MVS linkage editors allow such things as replacing individual control sections in an object module (i.e. replace individual functions in a C program that were compiled together into one object module) either implicitly or explicitly, changing the names of external symbols, explicit ordering of control sections within the load module being produced (this can be essential for getting good virtual memory performance in some situations), relinkediting load modules (ever wanted to run a binary that you didn't have source for through ld(1) to sub- stitute one routine?), aligning control sections on page boundaries for improved virtual memory performance, and several other useful things. IBM may do a lot of despicable things, but linkage editors are one thing that they designed a lot better than what UNIX users are stuck with. (Okay, bashers, fire at will. :-) Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "I, however, place economy amoung the first and most important * * of republican virtues, and public debt as the greatest of the * * dangers to be feared." --Thomas Jefferson * **********************************************************************