Mail Archives: djgpp/1995/04/20/13:43:32
> 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
- Raw text -