Hair-pulling, D, and Optlink

[Sean Kelly]

Sean Kelly wrote:
> Walter Bright wrote:
>> Lars Ivar Igesund wrote:
>>> kris wrote:
>>>
>>>> This problem is not limited to OMF files -- it shows up on linux too,
>>>> where ELF format is used.
>>>>
>>>> Sean asked why this issue does not crop up with DMC, or other C++
>>>> compilers supporting templates? I'd like to understand that too. Would
>>>> be nice if this (serious) difficulty were to get some lovin'
>>>
>>> Note that this has been reported before:
>>>
>>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/5951
>>>
>>> Walter promised to check out it, but I haven't noticed any replies. 
>>> Sitting
>>> around #D, I've gotten the impression that Mr Chancellor and others
>>> consider D's templates to be thouroughly broken due to these issues.
>>
>> It "works" in C++ because the compiler regenerates the template 
>> instantiation in *every* object file where it is used. The C++ 
>> compiler doesn't know about other object files.
>>
>> In D, when multiple sources are given on the command line, the 
>> compiler doesn't generate redundant template instantiations.
> 
> But Ares is built one object at a time via a makefile, so there are no 
> "multiple sources given on the command line."  Did you mean, perhaps, 
> that this is somehow related to how DMD treats modules vs. how DMC 
> treats source files?  ie. that the #include model effectively 
> copy/pastes code while importing modules does not?

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.

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.  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?  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?


Sean