Re: How C compilers handle multiple function definitions.

kamal <kamalpr@hp.com>
Thu, 1 Jan 2009 02:39:17 -0800 (PST)

          From comp.compilers

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)
| List of all articles for this month |

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



Post a followup to this message

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