Re: Multiply-defined global symbols

"Julian Brown" <brown@cs.bris.ac.uk> wrote in message
>
> I'm working on a port of GCC and Newlib to a new architecture, with my
> own assembler and linker(*). I have a question that I'm not having much
> luck finding the answer to. Mostly, my problem is with a "throwaway"
> remark in one of the Newlib configuration scripts:
>
> # The functions ldexp, frexp and modf are traditionally supplied in
> # both libc.a and libm.a. We build them in libm.a and copy them over,
> # along with some required supporting routines.
>
> Now, in my mind that means there will be multiple definitions of those
> functions, which will be an error when linking a program with the math
> library (-lm). And in fact, that's exactly what's happening unless I
> hack that particular "feature" out of Newlib.
>
> So, is my understanding of global symbols (perhaps with particular
> reference to libraries) generally incorrect? Is it OK to have multiple
> global definitions of the same functions? Should I be looking at the
> actual code referred to by the symbols and only complaining if it's
> different, or something? (yuck!)


As far as I know, it is usual not to load a routine from a library if
the symbol has already been resolved, either from the input or another
library.


The IBM S/360 linker, and presumably the successors, take the first
definition of an external symbol. There is an old trick to replace a
module in an already linked load module (executable file) by loading
the new replacement module, and then the old load module. The new one
will replace existing ones with the same name.


-- glen
[It's a little trickier with some implementations of shared libraries
where you either get all of the symbols or none of them. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.