Duplicate symbols (was Re: gcc-ss-20000612: installation failure on hppa2.0n-hp-hpux11.00)

H . J . Lu hjl@lucon.org
Sun Jun 25 16:05:00 GMT 2000


On Sun, Jun 25, 2000 at 12:45:15PM -0700, Michael K Vance wrote:
> > 	symbols in shared libraries.  As a results, applications end up
> > 	with two copies of these symbols and all hell breaks loose when
> > 	the application executes.  This problem can be avoided by using
> 
> This brings up an issue that we're struggling with in our Win32 ports,
> namely the fact that Windows appears to have a "hierarchical" run-time
> linker. For instance:
> 
> binary defines Com_Printf()
> game.so defines Com_Printf()
> 

Do you want to export Com_Printf () from game.so? If you don't want
to export it, it is trivial to do. But if you want to export it
from game.so, you will need glibc 2.2 for that feature. BTW, in
the ELF visibility term, Com_Printf is procteted in game.so.

> Under Win32, all calls to Com_Printf() in game.so will correctly resolve to
> the Com_Printf() defined inside it. We attempt to correct all these in our
> ports, but it gets to be a pain. Is there a particular reason that g++
> doesn't have game.so jump to its own versions automatically (through code
> generation) rather than depend on the run-time linker to resolve it?
> 
> HJ, et al, is there a chance that ld.so can be changed to this
> "hierarchical" resolution style?

We can do it under Linux and we can do it in more ways with glibc 2.2.
Send me a simple testcase. I will show you how to do it under Linux.

> 
> We've also noticed that linking statically  (ie, build game.so's objects
> directly into the binary) does *not* yield warnings for all duplicate
> symbols, even when -warn-common is specified for ld. Is there any reason for
> this?
> 

Send me a testcase. I will look into it.

H.J.


More information about the Gcc mailing list