Linker error

[Steven Schveighoffer]

On 1/21/19 5:28 PM, Jerry wrote:
> On Monday, 21 January 2019 at 21:02:23 UTC, Steven Schveighoffer wrote:
>> On 1/21/19 3:37 PM, Jerry wrote:
>>> [...]
>>
>> I had a similar problem that I fixed myself actually last dconf:
>>
>> https://issues.dlang.org/show_bug.cgi?id=17968
>>
>> This looks almost identical as the issue was in the generated xtoHash 
>> function.
>>
>> What version of the compiler are you using? My issue was fixed in 
>> 2.080.1, and then a followup fix in 2.081.1.
>>
> 
> Ok, I get the same linker error down to version 2.74. Below that my 
> eventcore version does not compile. Atleast LDC can compile so I can 
> move forward. I will try to dustmite this tomorrow.

This was a PITA for me when it happened (I used dustmite to go down to a 
pretty small version). I was essentially blocked on my work in iopipe 
until this was fixed.

The issue I ran starts with dmd generating a function xtoHash for 
structs where you don't define toHash. In certain cases (and these can 
be very weird indeed), dmd generates a function which, for each of its 
members, calls essentially typeid(x).toHash(&x).

In the case of a struct that contains a class reference, this all goes 
fine, but the compiler doesn't generate the TypeInfo for the class when 
it should in these certain cases (in particular, the TypeInfo_Const for 
that class reference).

The reason I feel like your error is very very similar, is because you 
show the missing symbol as being the InitZ, which is the TypeInfo 
initializer of something, and you see the symbol that requires it as 
being an xtoHash symbol.

Not knowing your code base, it's hard to know what exact situation 
you're in. But hopefully this helps you get an understanding as to why 
it might happen.

I think in my case, it was a template class in an auto function, within 
an import (hard now to remember the details). In fact, the root cause is 
still there, I just added a workaround in the xtoHash generation (that 
cheats and uses typeid(Object) instead of the real typeid, since it's a 
virtual function call anyway).

See the related bug report with the root cause: 
https://issues.dlang.org/show_bug.cgi?id=18833, maybe it helps you 
relate to what is happening.

-Steve