On Wed, Feb 23, 2005 at 02:50:13PM -0700, Davda, Bhavesh P (Bhavesh) wrote: > Well, yes and no. > > In general what you state is quite true. > > But there are always strange applications, and Avaya has one, where a > final executable is really a "merge" of what used to be independent > processes, with methods that also shared the same name, and data > structures and heaps that shared the same name. We employ an in-house > tool to "munge" the clashing symbols before finally linking the merged > executable, and then "un-munge" the symbols back, so that the final > executable *CAN* have multiple definitions of the same symbol names. > > Taking away the "-fno-weak" would make this quite painful to do with > template class instantiations, and we may have to resort to other > trickery like "munging" the "-S" assembly code generated to remove the > ".weak" directives before generating the .o's.
If you are munging the symbol table, then why on earth aren't you just removing STB_WEAK at the same time? When you abuse ELF like this, you've got to be prepared to run into its stranger corners; I don't think it's GCC's job to assist with this. > Is there anything in the C++ standard or ABI that dictates that template > class instantiations emit weak aliases for methods? I would seriously > doubt that since weak aliases are an ELF only manifest, aren't they? The C++ ABI that GCC follows actually mandates the use of COMDAT. I doubt that'll make things any easier for you. -- Daniel Jacobowitz CodeSourcery, LLC
