Re: How C compilers handle multiple function definitions.

On Dec 29 2008, 9:20 pm, "Armel" <armelasse...@hotmail.com> wrote:
> "RealCat" <typing...@gmail.com> a icrit
>
> > 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."?
> > Is there any standard behaviour for this case or does it vary with
> > compiler implimentations?
>
> from what I could see:
> - a library is mostly just the concatenation of several objects(=modules),
> so all the treatments are 'as if' the objects where provided in library
> build order, making a library _does not_ resolve references.


it actually does for HP-UX. Every function referenced but not defined
(and this should be true acrosss all platforms) will have a relocation
created by the compiler, which is processed by the linker. If the
linker fails to find a definition in another object file for a given
reference, only then it creates a PLT entry. Note that there can be
only one global definition per module, for there to be no warning from
linker stating that there is a duplication definition of a symbol.




> - libraries which intend to let some functions be overriden are built in a
> "one function per object/module" fashion, actually solving the above
> question.
>
you mean, by defining a function as static.


> It seems that there is no real standard shared by all _linkers_ but
> the "one function per object" paradigm makes your question simple
> enough to be sure that the _first_ "function module" is considered the
> one to choose


so how will you resolve references to that symbol if it is defined in
multiple object files within the same library?


> this technic is often used to override the 'malloc' function and add some
> debugging front end to it, while ensuring the linker will use your own
> version (listed before the -l of C library) is called by the C library
> itself.


that is something to do with forcing symbol resolution in a certain
way. But it doesn't mean you can have more than one definition per
module (assuming each is in a different object file thatw as
concatenated).


regards
-kamal

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