__init unresolved external when using C library structs converted with dstep

[Robert M. Münch]

On 2020-04-14 18:44:55 +0000, Steven Schveighoffer said:

> On 4/14/20 2:29 PM, Robert M. Münch wrote:
> 
>> Ah, ok. That's why the problem went (temporarly) away when I did a: 
>> myCstruct a = {0,0}; for example?
> 
> I don't know what causes it to be emitted when. Sometimes it doesn't 
> make a whole lot of sense to me.

Hu... I wouldn't expect this to behave arbitrary...

>> Yes, everything is "extern(C) :" for the complete import files.
> 
> Then apparently the compiler still expects to have initializers even 
> for foreign language structs.

Which surprised me, or more precise, I don't understand why these are 
not done implicitly using the D basic-type initializers.

>  This is not a huge issue though, as the structs are ABI compatible 
> even if compiled in D.

Yes, fortunately.

>>> Are you compiling the D file that contains the struct definition as well?
>> 
>> No. Is that the missing part?
>> 
> 
> Probably. I think the compiler expects whatever is compiling the 
> imported file to provide the symbol. If you aren't compiling it 
> separately, then you need to include it in the compilation.

The C lib contains the smybols and I thought that the compiler just 
needs the imports to get an idea about the structures, types, etc. and 
later on the links resolves everything.

But, it works when I explicitly add the import source files to the 
VisualD project. Not sure what difference this makes, because the 
source can be compiled without any problems with/without those files 
added. But it seems that the linker now sees different things.

What's strange is, that for a dub project that uses the same imports, I 
didn't had to add them to the dub.json file. There, it just works 
without any problems.

All a bit strange and confusing...

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster