RE: symbol collision

RE: symbol collision

[vijay nag]

Hello,

I have two functions with same name but with different proto-types
defined in two different libraries. 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.

 $] cat 1.h
#ifndef 1_H_
#define 1_H_

int zlib_compress(void);
#endif // 1_H_

$ cat 1.c

#include "1.h"
#include "2.h"

int zlib_compress(void)
{
  int a;
  crc32(&a);
}

]$ cat 2.h

#ifndef 2_H_
#define 2_H_

extern int crc32(int *a);
#endif // _2_H_

]$ cat main.c
#include <stdio.h>
#include "1.h"

int crc32(int a, int b)
{
  printf("crc32 in main.c\n");
}

int main()
{
  printf("Calling Zlib compress\n");
  zlib_compress();
}

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 ?

Re: symbol collision

[Ángel González]

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.