Hi there,
 I'm currently trying to set up a small demo project using the Leap Motion API in D.  I've run SWIG with -d -d2, and created the intermediate C++ DLL along with a pair of .d files, leap.d and leap_im.d.  I'm new to D, but very interested and I'd like to set this up in an idiomatic way & be able to share it, but I'm running into a problem: When I create a simple sample project with Visual D and import the Leap module, I get a number of linker errors:

Error 42: Symbol Undefined _D4Leap10Controller6__ctorMFZC4Leap10Controller (Leap.Controller Leap.Controller.__ctor())
Error 42: Symbol Undefined _D4Leap10Controller7__ClassZ
Error 42: Symbol Undefined _D4Leap12__ModuleInfoZ

I've discovered that if I run dmd manually and link in the object files for leap.d and leap_im.d, these problems go away, and if I create a separate project to build a .lib and then link to that it also solves the issue.  Both of these options seem hacky to me though, and I'm wondering if there's some 3rd option I'm missing - the files contain the entire definitions, so why would it be necessary to link to them AND specify them as imports?  What am I missing here?

On Wed, 23 Apr 2014 20:34:11 -0400, Walter Gray <walter.r.gray@gmail.com> wrote:

> Hi there,
>   I'm currently trying to set up a small demo project using the Leap Motion API in D.  I've run SWIG with -d -d2, and created the intermediate C++ DLL along with a pair of .d files, leap.d and leap_im.d.  I'm new to D, but very interested and I'd like to set this up in an idiomatic way & be able to share it, but I'm running into a problem: When I create a simple sample project with Visual D and import the Leap module, I get a number of linker errors:
>
> Error 42: Symbol Undefined _D4Leap10Controller6__ctorMFZC4Leap10Controller (Leap.Controller Leap.Controller.__ctor())
> Error 42: Symbol Undefined _D4Leap10Controller7__ClassZ
> Error 42: Symbol Undefined _D4Leap12__ModuleInfoZ
>
> I've discovered that if I run dmd manually and link in the object files for leap.d and leap_im.d, these problems go away, and if I create a separate project to build a .lib and then link to that it also solves the issue.  Both of these options seem hacky to me though, and I'm wondering if there's some 3rd option I'm missing - the files contain the entire definitions, so why would it be necessary to link to them AND specify them as imports?  What am I missing here?

Every module in D generates a moduleinfo object. The runtime links all these together and uses it to run static constructors and destructors. It also contains runtime type info for any items defined within the module.

Even if a module has only templates, or even if it's empty! You still have to compile and include it in the link step if it's imported from a module you are compiling.

As for Visual D, I don't know much about how it works.

-Steve

Walter Gray:

> the files contain the entire definitions, so why would it be
> necessary to link to them AND specify them as imports?
> What am I missing here?

I don't understand why that's not regarded as a job for the compiler. But in the standard D distribution there are programs like rdmd that offer that functionality.

Bye,
bearophile