__init unresolved external when using C library structs converted with dstep
schveiguy at gmail.com
Thu Apr 16 12:41:44 UTC 2020
On 4/16/20 5:20 AM, Robert M. Münch wrote:
> On 2020-04-15 15:18:43 +0000, Steven Schveighoffer said:
> The difference is you are telling the compiler that it should generate
> any symbols for those types. If you just import them, then it's
> expecting something else to build those symbols.
> Maybe I'm a bit confused, but that's quite different to a C compiler,
> right? If I include header and have a .lib things fit.
C doesn't have initializer data for structs, because C doesn't
initialize anything for you ;) So there is no data that needs to be
defined somewhere, a C struct is just a compiler entity.
This is why I wasn't sure if extern(C) structs were required by D to
have initializers. But it makes sense, because D is still going to
initialize your C structs.
> With D I have a .lib, I have the imports and still need the imports
> somehow compiled (included in project, or as a 2nd .lib) to make
> everything work. Do I understand that correct?
if the .lib is compiled by C it does not include the initializer. But D
If the .lib is compiled by D, then it should have the initializer in it.
> You could also build a library that builds those symbols, and link in
> that library instead.
> That would be the 2nd .lib approach than.
Yes. That is why D wrapper bindings for C libraries need their own library.
> 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.
> dub builds all dependencies so this is like the library solution.
> But I didn't include the library as a dub dependency. I just have the
> C/C++ compiled lib file and the D imports path for this lib.
Perhaps dub is being over-zealous when given imports. Maybe instead of
importing using -I, it's compiling the import directly.
Check the command line that it's using by doing dub -v.
More information about the Digitalmars-d-learn