Hair-pulling, D, and Optlink

Walter Bright newshound at
Fri Apr 21 19:53:15 PDT 2006

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.

More information about the Digitalmars-d-bugs mailing list