How to make gcc give a check about symbol conflicts in shared libraries it links?

How to make gcc give a check about symbol conflicts in shared libraries it links?

[xiaxia347work]

Hi,   
     I got a tricky problem when I link my exe program with 2 shared libraries,
 the global variable with same name in the  2 .so file may be linked to the same
 address, resulting problem that is hard to find.  
    
here is the situation:
  
test1.c:  
int global = 1;  
void func1(void) {  
    printf("test1 : %d.\n", global);  
}  
gcc -shared -o test1.so test1.c  

test2.c:  
int global = 2;  
void func2(void) {  
    printf("test2 : %d.\n", global);  
}  
gcc -shared -o test2.so test2.c  

main.c  
int main()  
{  
    func1();  
    func2();  
}  
gcc -c -o main.o main.c  
gcc -o main main.o test1.so test2.so  

then the result would show that the global is set to 1 , one address. something like following is printed:   
"test1 1."  
"test2 1."  

I know this is not a standard way to create shared library for thatit exports all symbols,
 but what I am looking for is  when the main program link the shared libraries, it
 should do a check about whether there is some fucntions/global variables have
 the same name. If that is true, report that or at least give a warning. I have searched
 quite a lot of pages but get no answer, maybe there is an option for gcc could do this?
 otherwise I think there is really some risk when linking shared libraries that
 is not written well.  

Best Regards  
                                                            Wayne Xia  

Re: How to make gcc give a check about symbol conflicts in shared libraries it links?

[Ian Lance Taylor]

"xiaxia347work"<xiaxia347work@163.com> writes:

>      I got a tricky problem when I link my exe program with 2 shared libraries,
>  the global variable with same name in the  2 .so file may be linked to the same
>  address, resulting problem that is hard to find.  

This is not a gcc issue.

You didn't mention which OS you are using.  I will assume it is
GNU/Linux.  On GNU/Linux, or any other ELF based system, there is a
single global namespace of global variables and functions.  When two
shared libraries use the same global variable name, they are referring
to the same variable.  This is a feature.

If you want something different to happen, look into symbol visibility
and linker version scripts.

Ian

Re: Re: How to make gcc give a check about symbol conflicts in shared libraries it links?

[xiaxia347work]

    Thanks for the infomation. I am using Ubuntu10 with a Linux2.6 kernel on x86 system, and installed the
 gcc tool chain with x86/arm target.
    From my understanding,  there should be two chances to give a check about the symbol naming conflict:
One is when the gcc tool chain try to link the .o file and .so file into the executable file, Two is before it is run the
loader of the system could check if there are functions or names having same name in which it would load to
 memory. So the gcc would have a chance to do that.
    The scenario is that: I got two .so file from other project. Not considering how it is created, as the user of these
 .so files, I want make sure there would be no confilict that would affect .so's behavior otherwise there would be
 hidden errors very hard to find. If there is same name in one namespace, report it.
    Checked about the visibilty feature, I think it is a controlling method  about what is exportd when .so was
 created but not a checking method when .so was linked.  I have little knowledge about gcc internal, could u give
more information about the " linker version scripts."? I am also wondering if there is a simple way to tell gcc check
 for the name conflict when it link .so files.

Best Regards
 
                                                                                                                                     Wayne Xia
2011-11-08
-----------------------------------------------------------------------------------------
发件人:  Ian Lance Taylor <iant@google.com>
发送时间:  2011-11-07 23:33
主   题:  Re: How to make gcc give a check about symbol conflicts in shared libraries it links?
收件人:  "xiaxia347work"<xiaxia347work@163.com>
抄   送:  "gcc-help"<gcc-help@gcc.gnu.org>




"xiaxia347work"<xiaxia347work@163.com> writes:

>      I got a tricky problem when I link my exe program with 2 shared libraries,
>  the global variable with same name in the  2 .so file may be linked to the same
>  address, resulting problem that is hard to find.  

This is not a gcc issue.

You didn't mention which OS you are using.  I will assume it is
GNU/Linux.  On GNU/Linux, or any other ELF based system, there is a
single global namespace of global variables and functions.  When two
shared libraries use the same global variable name, they are referring
to the same variable.  This is a feature.

If you want something different to happen, look into symbol visibility
and linker version scripts.

Ian

Re: How to make gcc give a check about symbol conflicts in shared libraries it links?

[Ian Lance Taylor]

"xiaxia347work"<xiaxia347work@163.com> writes:

>     From my understanding,  there should be two chances to give a check about the symbol naming conflict:
> One is when the gcc tool chain try to link the .o file and .so file into the executable file, Two is before it is run the
> loader of the system could check if there are functions or names having same name in which it would load to
>  memory. So the gcc would have a chance to do that.

On ELF systems it is normal and useful for two different shared
libraries, or the executable and a shared library, to define the same
name.  This is use for symbol interposition.


>     Checked about the visibilty feature, I think it is a controlling method  about what is exportd when .so was
>  created but not a checking method when .so was linked.  I have little knowledge about gcc internal, could u give
> more information about the " linker version scripts."? I am also wondering if there is a simple way to tell gcc check
>  for the name conflict when it link .so files.


As I said earlier, this is not a gcc issue.  What matters here is ELF
and ELF semantics, not gcc or anything that gcc does.  This is all
controlled by the linker and the dynamic linker, not by gcc.

For linker version scripts, see
http://sourceware.org/binutils/docs-2.21/ld/VERSION.html

Ian

回复: Re: How to make gcc give a check about symbol conflicts in shared libraries it links?

[xiaxia347work]

Got you idea, many thanks. I would check more about the linker to see if there is a solution for this, thanks!


------------------
Best Regards
 
                                                                                      Wayne Xia
2011-11-08
-----------------------------------------------------------------------------------------
发件人:  Ian Lance Taylor <iant@google.com>
发送时间:  2011-11-08 13:57
主   题:  Re: How to make gcc give a check about symbol conflicts in shared libraries it links?
收件人:  "xiaxia347work"<xiaxia347work@163.com>
抄   送:  "gcc-help"<gcc-help@gcc.gnu.org>




"xiaxia347work"<xiaxia347work@163.com> writes:

>     From my understanding,  there should be two chances to give a check about the symbol naming conflict:
> One is when the gcc tool chain try to link the .o file and .so file into the executable file, Two is before it is run the
> loader of the system could check if there are functions or names having same name in which it would load to
>  memory. So the gcc would have a chance to do that.

On ELF systems it is normal and useful for two different shared
libraries, or the executable and a shared library, to define the same
name.  This is use for symbol interposition.


>     Checked about the visibilty feature, I think it is a controlling method  about what is exportd when .so was
>  created but not a checking method when .so was linked.  I have little knowledge about gcc internal, could u give
> more information about the " linker version scripts."? I am also wondering if there is a simple way to tell gcc check
>  for the name conflict when it link .so files.


As I said earlier, this is not a gcc issue.  What matters here is ELF
and ELF semantics, not gcc or anything that gcc does.  This is all
controlled by the linker and the dynamic linker, not by gcc.

For linker version scripts, see
http://sourceware.org/binutils/docs-2.21/ld/VERSION.html

Ian