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: | Derk Gwen <derkgwen@HotPOP.com> |
Newsgroups: | comp.compilers |
Date: | 6 Oct 2003 21:23:57 -0400 |
Organization: | Quick STOP Groceries |
References: | 03-10-012 |
Keywords: | linker |
Posted-Date: | 06 Oct 2003 21:23:57 EDT |
# 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.
What is normally done is that first all external definitions in the
object files you give (*.o) are catalogged. Multiple definitions here
should give a diagnostic. Undefined externals are collected in a list.
Next the loader will go through libraries in the order given looking
for definitions of undefined externals. As the definitions are found,
they are added to the catalog of defined externals, and any undefined
externals in the loaded module are added to that list. Once all
modules in the library have been checked, then the next library is
searched to satisfy remaining undefined externals. This continues
until all libraries are searched or all externals defined. Remaining
unsatisfied weak externals do not cause a diagnostic, but other
unsatisfied externals should.
(Up to about 10, 15 years ago, once a library was searched,
definitions in modules not needed were forgotten when the next library
was searched. This meant new undefined externals in later libraries
were not satisfied by previous libraries. This sometime led to a
library being listed more than once to the loader, and it made the
order in which libraries were listed very important.)
If you want to override an external defined in libc or libm or libX11
or whereever else, you should be able to do by defining the entrypoint
in your own object files, or in another library linked before the
others. This is a technique to update implementations to the same
interface without recompiling the base implementation. Useful for
experiments and special cases.
(On a old 65 Kbyte C I used, the libc didn't have floating point
support in printf. If you needed it, you just linked libm before libc,
and libm would have a full implementation of printf.)
# 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!)
Library modules are only linked on need. If not needed, whether they duplicate
already linked externals is irrelevant.
--
Derk Gwen http://derkgwen.250free.com/html/index.html
So....that would make Bethany part black?
Return to the
comp.compilers page.
Search the
comp.compilers archives again.