Question

I have a dll, which accesses some classes outside of its project (I’m using Visual Studio, so I have two projects). The thing is, in the header that the dll includes, which is outside of the dll’s project, there are only bodies of functions, like this:

x.h

class x
{
    void myFunc();
}

And in another cpp file, outside of the dll file:

#include "x.h"

x::myFunc()
{
    //.....
}

The dll is only getting the bodies of the functions, so when I compile, I get lots of unresolved external symbols (I’m quite sure that this is the issue, because I tested with another class fully built in a .h file, in another project, and no errors). So how can I solve this mystery?

Answer 1

It is normal for the import headers to only have function signatures; the actual function bodies are already compiled into the DLL binary and are resolved at link time by linking into the actual DLL.

The first thing to try is to make sure you are actually linking to the said DLL. It isn’t enough to just include the header, you also need to link to the binary. So in your project configuration, you need to add a link to (for example) the .lib file that gets created along-side the DLL when the DLL is compiled (if in MSVC). This lib file lets the linker know how to connect the function signatures you included via the import header to the actual implementations contained in the DLL. If you’re on a different platform, the mechanics might be a little different, but the concepts will be similar.

Edits:
The next step is to make sure the binary is actually exporting the symbols you’re trying to link against. Make sure that all interface signatures are being exported via __declspec(dll_export) prefixes. Normally this is wrapped up in an IFDEF so that the header is declared export while the DLL is being compiled, but not when that header is included in a client project. Next, you could use dumpbin to check the mangled export names, and see if there is anything unexpected.

Here’s a modified version of your example that illustrates this style of export (note, I haven’t tested if this compiles, apologies for any typos):

#ifdef BUILDING_MYDLL
#define MYDLL_API __declspec(dllexport)
#else
#define MYDLL_API __declspec(dllimport)
#endif

class MYDLL_API x
{
    void myFunc();
}

You would then set your configuration to define BUILDING_MYDLL when compiling the dll, but not when compiling the executable. This way the functions are only marked export when compiling the library dll. Now you can mark your public API functions with MYDLL_API and they should get exported during build.

Please note that dll_export, dll_import, and declspec are all very MSVC-specific constructs. Other compilers/runtimes handle symbol export in different ways.