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@xxxxxxxxxx>
发送时间: 2011-11-08 13:57
主 题: Re: How to make gcc give a check about symbol conflicts in shared libraries it links?
收件人: "xiaxia347work"<xiaxia347work@xxxxxxx>
抄 送: "gcc-help"<gcc-help@xxxxxxxxxxx>
"xiaxia347work"<xiaxia347work@xxxxxxx> 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
