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
needs it.
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.
-Steve
