Re: symbol collision

[Ángel González <keisial at gmail dot com>]

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

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
> [linker]$./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.