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

["Michael K Vance" <briareos at lokigames dot com>]

> 	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()

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'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?

Any pointers to previous discussions on this topic are appreciated.

m.

--
"Advocating a system based on consumption is the ultimate violence against
poor nations."
-Masamune  Shirow