Related articles |
---|
Multiply-defined global symbols brown@cs.bris.ac.uk (Julian Brown) (2003-10-04) |
Re: Multiply-defined global symbols gah@ugcs.caltech.edu (Glen Herrmannsfeldt) (2003-10-06) |
Re: Multiply-defined global symbols derkgwen@HotPOP.com (Derk Gwen) (2003-10-06) |
Re: Multiply-defined global symbols kenrose@tfb.com (Ken Rose) (2003-10-06) |
From: | Ken Rose <kenrose@tfb.com> |
Newsgroups: | comp.compilers |
Date: | 6 Oct 2003 21:32:47 -0400 |
Organization: | Posted via Supernews, http://www.supernews.com |
References: | 03-10-012 |
Keywords: | linker |
Posted-Date: | 06 Oct 2003 21:32:47 EDT |
Julian Brown wrote:
> I'm working on a port of GCC and Newlib to a new architecture, with my
> own assembler and linker(*).
<problem discussion snipped>
> 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!)
Yes, it is OK. Assuming the library is organized in the usual
fashion, it's almost certain that only one instance of the function
will be linked in. It sounds like your linker is bringing in the
entire library, rather than just the parts that are needed.
> * At the time I felt my architecture was sufficiently "different" to
> warrant this, rather than porting the GNU tools.
I can understand that. You might want to consider using GNU ld with
your custom assembler, assuming you output some standard object file
format. I was involved in a project that did essentially that.
Beware, though, that some of the relocation code in BFD has a fit if a
relocation extends over more than 32 bits for a 32-bit target.
Unfortunately, I don't remember the details.
- ken
Return to the
comp.compilers page.
Search the
comp.compilers archives again.