OPTLINK needs to die.

[Walter Bright]

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.