This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Duplicate symbols (was Re: gcc-ss-20000612: installation failure on hppa2.0n-hp-hpux11.00)
- To: briareos at lokigames dot com
- Subject: Re: Duplicate symbols (was Re: gcc-ss-20000612: installation failure on hppa2.0n-hp-hpux11.00)
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Sun, 25 Jun 2000 15:56:25 -0400
- cc: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>, gcc at gcc dot gnu dot org
>>>>> "Michael K Vance" writes:
Michael> Under Win32, all calls to Com_Printf() in game.so will correctly resolve to
Michael> the Com_Printf() defined inside it. We attempt to correct all these in our
Michael> ports, but it gets to be a pain. Is there a particular reason that g++
Michael> doesn't have game.so jump to its own versions automatically (through code
Michael> generation) rather than depend on the run-time linker to resolve it?
Michael> Any pointers to previous discussions on this topic are appreciated.
This sounds like an issue of symbol scoping and versioning of ELF
libraries. game.so needs to be constructed with symbol scoping so that
references to some or all local symbols get resolved within the library.
This specifically prevents the overriding of LD_PRELOAD, I believe. AIX
XCOFF libraries resolve internally by default.
This is not an issue of G++ or ld.so semantics, this is an issue
of how game.so is built and what flexibility it needs. ELF is defined to
work this way. You probably want to discuss this on the GNU binutils /
GNU ld mailinglists and newsgroups.
David