Path: utzoo!attcan!uunet!lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!news.cs.indiana.edu!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!gacvx2.gac.edu!scott From: scott@erick.gac.edu (Scott Hess) Newsgroups: comp.sys.next Subject: Re: Library function redefinition Message-ID: Date: 1 Mar 91 19:22:36 GMT References: <1991Feb28.190319.22658@usenet.ins.cwru.edu> <1991Mar1.143756.12400@usenet.ins.cwru.edu> Organization: Gustavus Adolphus College Lines: 30 Nntp-Posting-Host: erick.gac.edu In-reply-to: chet@odin.INS.CWRU.Edu's message of 1 Mar 91 14:37:56 GMTLines: 30 In article <1991Mar1.143756.12400@usenet.ins.cwru.edu> chet@odin.INS.CWRU.Edu (Chet Ramey) writes: The `traditional' Unix linker satisfies only unresolved external references from libraries. This allows you to provide an application with a custom malloc, for instance, and have all of the libraries that use malloc cooperate. It seems that the NeXT/Mach ld simply maps the library into my process's address space, and damn any symbols that I already defined. What I would like is a switch to cc or ld that restores the traditional behavior, even in the presence of shared libraries. If it can't be done, that's OK, too. Hmm. Something has just occurred to me - how in the world does the libMallocDebug.a library work? Presumably, the malloc and malloczone stuff is in the shared libraries, right? But, where is it in the MallocDebug library? Since it uses different calls, at the very least the routines are not the regular ones - whether they are shared or not makes no difference. So, apparently there's something that can be done to "fix" the multiply-defined thing, because otherwise we'd have multiple declaration problems with MallocDebug. Anybody know what that "fix" was? Later, -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad "Tried anarchy, once. Found it had too many constraints . . ." "Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by Richard Simmons . . ."