Hair-pulling, D, and Optlink
sean at f4.ca
Fri Apr 21 13:11:34 PDT 2006
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:
>>> Walter promised to check out it, but I haven't noticed any replies.
>>> 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?
More information about the Digitalmars-d-bugs