Walter Bright wrote:
Tom S wrote:
Walter Bright wrote:
The problem appears to be that optlink cannot deal correctly with
weak references. I've modified the compiler to not emit weak
references, and the problem goes away. It's not a perfect fix, but it
works.
With the modified compiler, does the following link?
Yes.
If so, is the output correct?
[...]
I'm getting:
&aC.x == 419c30
&bC.x == 419c30
Yes, that is correct (there should be only one instance in the executable).
I'm afraid that it might refuse to link and then even if OPTLINK
allowed multiple strong symbols of the same name, I'd expect the
assertion to fail. Aren't weak symbols essential to properly handling
templates?
No. Weak references are: "if this symbol does not get resolved, then
default initialize it to this other symbol". In other words, weak
references do not cause things to be pulled in from the library.
Multiple symbols with the same name and same contents, across different
object files, are called COMDATs and the linker picks one and discards
the duplicates.
Where the compiler was emitting weak references was in the list of which
modules are imported by the object file, so that if nobody actually
referred to the import's contents beyond the import statement, the
import would not get linked in.
Of course compiling the modules together causes only one symbol to be
emitted for the template instantiations. Yet this is not an option for
a larger project, since compilation times and memory usage can get
rather high.
I know. This is why COMDATs were invented (for C++ templates). C++ drove
a number of improvements in obj files.
I'm glad to be proven wrong :) Thanks for the info! I'm sure it will
come in handy for the dynamic linking I'm doing with DDL. I got the
silly idea that you'd disable COMDATs... Another case of "Too much blood
in my caffeine".
--
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
