Undefined function, even though imported

[Jonathan M Davis]

On 2011-06-13 14:18, Loopback wrote:
> Hi!
> 
> Let me begin by saying, I'm sorry if this is caused of some obvious
> error but since I am new to D, I am not aware of all the tricks and
> treats it offers.
> 
> I am working with the WindowsAPI binding at dsource.org (though I do not
> believe this is related to the binding itself). However, in my code I
> call the function LOWORD (win32 specific). This function is defined in
> the win32.windef module. Although it is defined there (without any
> encapsulations in version statements or anything similar) I receive this
> error:
> 
> Error 42: Symbol Undefined _D5win326windef6LOWORDFkZt (LOWORD undefined)
> 
> To solve this I had to copy-paste the exact function directly into my
> own file/module instead. So my question is the following; why do I have
> to copy and paste the function directly in my code when it is clearly
> defined in one of the files I import?
> 
> Windef.d attached

Importing the module with the function in it means that the compilation of the 
current module can see that module and use its symbols. But the compiled 
functions in the imported module are in the object file generated when 
compiling that module, not the current module. In the case of binding to a C 
function, you're telling D that a function with that signature exists, but it 
doesn't have the source to it. In either case, the actual function definition 
is going to be needed when linking (at least with static linking - it's a bit 
more complicated with dynamic linking, but on Windows at least, the .lib file 
still needs to be linked in). In this particular case, one of two things is 
likely happening.

1. You never linked in the lib file for the library with the function.

2. The declaration given for the C function in question isn't using the right 
linking. That is, it needs to be extern(C) and/or extern(Windows) (I'm not 
quite sure what extern(Windows) does differently than extern(C), but I gather 
that it's necessary at least some of the time when dealing with Windows system 
functions).

The symbol that it's complaining about looks rather mangled to me (though I 
don't look at pure C function symbols very often, so I don't know exactly what 
they look like unmangled - both C++ and D mangle functions to allow for 
function overloading). So, it's likely that the function's declaration in D 
isn't properly marked with extern(C) or extern(Windows). So, the function's 
name gets mangled, and it can't find the unmangled C function in the .lib 
file.

Regardless, that particular error indicates that the linker failed to locate 
that particular function, and you have to make whatever changes are necessary 
- either in code or in your compilation process - to make it so that the 
linker is able to find the definition of the function in question.

- Jonathan M Davis