Hair-pulling, D, and Optlink
foo at bar.com
Fri Apr 21 11:02:07 PDT 2006
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'
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.
More information about the Digitalmars-d-bugs