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.
