Hair-pulling, D, and Optlink

[kris]

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'

- Kris


Sean Kelly wrote:
> Walter wrote:
> 
>> "John Reimer" <brk_6502 at yahoo.com> wrote in message
>> news:d6bg0g$2ufn$1 at digitaldaemon.com...
>>
>>> This has the potential for being a quite troublsome problem.  Dool has
>>> several template-only object files in the lib.  Problems with the other
>>> objects in the lib haven't shown up because they are being used yet in a
>>> project. :-(  Linux is free of this problem, thankfully.
> 
> 
> I just ran into this while merging some additional Mango code into Ares. 
>  Fortunately, this thread was fairly easy to track down, but 
> implementing the fix has required changing almost 10 files so far, and 
> Ares includes a very minimal portion of Mango.  I have no idea why Mango 
> itself doesn't have this problem, but it seems I'm stuck with it.  And 
> while this is merely annoying so far, I can see this becoming a real 
> maintenance problem down the road.
> 
>>> So there is no possibility of a fix for this?  Is it quite complicated
>>> to repair? Perhaps it's a problem with the legacy OMF format.  Your
>>> technique fixed the problem like you said, but I'd have to start adding
>>> it to several object files in the library; dool has minimum coupling, so
>>> in order to fix the problems I'd have to reverse this fact and start
>>> making spaghetti imports in the library.
>>>
>>> Thank you very much for the solution, though.  I can get by for now.
>>
>>
>> It's a problem with the OMF format. It isn't easilly fixable.
> 
> 
> Why isn't this a problem with C++ template code?  A module is roughly 
> the same as a C++ translation unit, so I imagine the same problem must 
> occur there as well.
> 
> Here's Walter's description of the problem for reference:
> ----------
> 
> The problem is that when templates are instantiated, they are inserted into
> an object file record called a COMDAT. COMDATs have the necessary feature
> that if multiple object files have a COMDAT with the same name, the
> duplicates are discarded.
> 
> This feature is necessary for template instantiations, since the compiler
> compiling one module doesn't know about the same templates being
> instantiated by another module.
> 
> An unfortunate side effect is that the one cannot pull object files out 
> of a
> library by referencing COMDATs alone, one must reference something else in
> that object file, too.
> 
> The dmdscript.lib library has the same problem with protoerror.d. I solved
> it with the kludge of inserting:
> 
>     int foo;
> 
> into the file, and then referencing it in dobject.d with:
> 
>     int* pfoo = &dmdscript.protoerror.foo;
> 
> Not too pretty, but it works.