Sean Kelly wrote:
> Let me clarify a bit further.  The problem I ran into when importing Mango code into Ares was that when modules with non-template code instantiated template code also defined in the library, then I'd get a link error when attempting to use that non-template library code in an application.  I speculated that perhaps the template code simply wasn't being generated for some reason so I ran obj2asm on the library object files and found I was wrong--so far as I could tell, the template code had been instantiated into the object file of every module using the code.  But that's as far as I got.  I wondered if perhaps the code was perhaps being thrown out by the 'lib' tool, but didn't make much progress inspecting the library code itself.  Further, it seems kind of odd that the same problem seems to occur on Linux, which has a different object file format AFAIK.

If the template instantiation occurs in an object file that is put into a library, the name associated with it is *not* inserted into the library's symbol table. Thus, the linker won't find it when searching a library for the name, even if the name is defined in every object file in that library. This exact same thing happens with C++, except you don't notice it because the template instantiation is *also* inserted into every object file that references that template instantiation, including the non-library application code. If just one of those gets linked in by either linking in the object file directly or by having another reference to an object file that instantiates the template, then  the linker will see it.

> Aside from the workaround you suggest a while back--adding 'fake' non-template data and referencing it in the appropriate places--are there any other options for library writers?  Your proposed solution works (or it did for me at any rate), but it's a nasty hack that I don't see being well-accepted in the long term.  Implementation complexity aside, I would be happy with even "broken" code generation similar to how C++ object files are created if it would actually solve this problem without introducing a host of new ones.

The C++ solution sucks because it (often) creates massive object files and slow compilation times.

> But I still don't entirely understand what's going on.  Is the problem truly in code generation or does it occur later during library assembly or during linking?

The problem is the object file format. There is no way to specify "if multiple instances of this name occur, discard all but one" along with "include this name in the library dictionary."


> And are there any alternatives such as different object file formats that might correct this as well?  From your discussion of COMDATs I don't understand why this would be a problem on Linux as well, unless perhaps the object files have a similarly bad design?

ELF does things the same braindamaged way. Sheesh, ELF doesn't even support "discard this name if nobody references it", a feature commonly found on DOS object formats 25 years ago.

Thanks for the clear explanation.  I now feel like I have a reasonable understanding of the problem, even if I'm no closer to a solution :-)


Sean