Hair-pulling, D, and Optlink

Sean Kelly sean at f4.ca
Wed Apr 5 16:14:17 PDT 2006


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.



More information about the Digitalmars-d mailing list