Related articles |
---|
How C compilers handle multiple function definitions. typingcat@gmail.com (RealCat) (2008-12-28) |
Re: How C compilers handle multiple function definitions. armelasselin@hotmail.com (Armel) (2008-12-29) |
Re: How C compilers handle multiple function definitions. mburrel@uwo.ca (Mike Burrell) (2008-12-29) |
Re: How C compilers handle multiple function definitions. gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-12-30) |
Re: How C compilers handle multiple function definitions. kamalpr@hp.com (kamal) (2009-01-01) |
Re: How C compilers handle multiple function definitions. kamalpr@hp.com (kamal) (2009-01-01) |
From: | kamal <kamalpr@hp.com> |
Newsgroups: | comp.compilers |
Date: | Thu, 1 Jan 2009 02:39:17 -0800 (PST) |
Organization: | Compilers Central |
References: | 08-12-107 |
Keywords: | linker |
Posted-Date: | 01 Jan 2009 11:15:39 EST |
On Dec 29 2008, 7:12 am, RealCat <typing...@gmail.com> wrote:
> If there are functions whose names are the same in object files and
> library files, what should happen during the compliation? Should this
> always cause a link error, or can C compilers make assumptions such
> as : "function definition in the object file has higher precedence
> over the one in the library file" or "the one in the previously linked
> library file has higher precedence over the ones in the library files
> linked later."?
[This description is specific to ELF linkers and loaders used in Unix
and similar systems including Linux and *bsd. -John]
yes the dynamic loader (and not the linker) makes such asumptions when
it resolves symbols. The linker, for its part will create a PLT
(procedure linkage table) entry if it cannot resolve the symbol. So,
if you have a function f() references in the object file and also
defined in it, the linker will not create a PLT entry for f(). If the
linker happens to create a PLT entry for f(), then the dynamic loader
will do its job of resolving symbols based on precedence as you stated
above. Typically,
-first look if the symbol exists within the same library or dependent
libs
-look at global exported symbols in libraries above (as in enclosing
scope)
> Is there any standard behaviour for this case or does it vary with
> compiler implimentations?
it can only vary with the linker/loader implementation and not the
compiler's implementation.
> [Usually linkers only pull in library routines that satisfy unresolved
> references, so if there's a duplicate, the linker just ignores it. A
> more interesting question is what happens when the program has a definition
> of A and a reference to B, and a library module defines both A and B.
> -John]
In that case, the PLT entry for B will be filled up to point to
library module's definition of B. Since A was defined and never
referenced outside of the program, there won't be a PLT entry in the
first place to choose between the 2 definitions.
regards
-kamal
Return to the
comp.compilers page.
Search the
comp.compilers archives again.