This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: symbol collision

On 06/11/13 19:50, vijay nag wrote:

Hello Vijay,

Please, try not to direct your question to multiple mailing lists at once.

I have two functions with same name but with different proto-types
defined in two different libraries.
Note that the different proto-types are irrelevant here, as at symbol level
both functions have the same signature.

Somehow linker seems to be picking
silently(no multiple definition errors) unmatched version of the
function while linking.

To illustrate the problem, I created an example code-snippet with the
following arrangement.

The executable "main" was created the following way.

[linker]$ gcc -I./ 1.c -c
[linker]$ gcc -I./ 2.c -c
[linker]$ ar rcs lib12.a 1.o 2.o
[linker]$ gcc main.o -L./ -l12 -o main
Calling Zlib compress
crc32 in main.c

Here I was expecting linker to throw multiple-definition error perhaps
it choose "crc32(int, int)" defined in main.o to link in the final
executable.  Any reason why linker is choosing "crc32" from main.o
rather than from lib12.a itself ?
I think that's because the symbol resolution with the libraries roughly:
- Pull all the main.o exported and imported symbols
- As main.o needs a symbol provided by the library, load it, pulling the library symbols. - Match the symbols with its definition, as main.o crc32 was defined first, it is chosen.

Note however that if you linked with 1.o and 2.o directly, ld wouldn't be "lazy" with the library, and you would get the multiple-defined-symbol error. Or if the other crc32 was provided in another object passed after -l12, as it would collide with the loaded definition from lib12.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]