This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


>>>>> "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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]