Date: Thu, 20 Apr 95 09:27:24 EDT
From: den AT aisinc DOT com (Dave New)
To: djgpp AT sun DOT soe DOT clarkson DOT edu, ckann AT seas DOT gwu DOT edu
Subject: Re: Multiple references in a link step

 
> I am trying to link a program which has redefined a number of standard
> functions (such as malloc).  When I use ld to link, I get a message
> that the function has multiple definitions.  I want to use the functions
> with the package, not the standard ones.  
> 
> If I use the -nonstandard flag, I lose all the definitions.  How can
> I get ld to use the redefined functions but still use the standard 
> libraries?
> 
> Chuck Kann
> 
I suspect that you will need to do some sleuthing to find what other references
are sucking in the standard library functions.  We have encountered such
situations using the GNU toolset on SunOS for cross-compiling for i960.

Usually what happens is that if you replace one function contained in standard
file with another function in a new file, you must replace all the functions in
the standard file, or else ensure that none of the other functions are ever 
referenced by anything else in that link.

For instance, you may replace malloc() but not other functions that may exist
in the same standard source file.  A reference to any of those other functions 
will suck in the standard object that contains the old malloc(), producing 
multiple references to malloc().

Also, global variables defined in the standard file will do the same thing.  
Maybe _brk or _sbrk is defined in the standard file, and your new routine (or 
some other) references these variables.  If these definitions aren't moved to 
your new code, then references to them will suck in the file that defines 
them.  Result: multiple definitions for everything else in the file that you 
re-wrote in your new file.

Turning on -M and -v (map and verbose) in the linker phase will create a rather
long list of why things were loaded in.  This can help, but it can be
pretty confusing reading the output.  Searching for 'malloc' with a text editor
on the resulting output will help target the areas to be investigated pretty
quickly.

Also, using the -y option (over and over, if necessary) to interrogate the 
linker about references to the named symbol may help, but gets unwieldy very 
quickly, if you must search through multiple levels of references.

What the GNU toolset *really* needs is a good cross-reference generator.  This
would quickly ferret out these kinds of problems.  I'm not aware of one (any
information/takers?).  We have a cross-reference tool on the SunOS, but it 
doesn't understand ANSI C (8-p).  We target C for ROMs as well as our own 
runtime environment, and sucking in standard things like malloc(), etc., are 
deadly.  Whenever this happens, it costs us a day or two to track down the 
culprit -- a real waste of time.

DaveN