LNK2019 problem

Question

I have a LNK2019 problem when trying to use some DLL in my project.

Details:

1. I have a DLL project called dll1; that compiled just fine (using __d

Answer 1

Just a guess:

If you include the header from dll1 in the dll2 project and in that header you use the __declspec(dllexport)) you tell the linker that dll2 is also exporting these classes that actually are meant to be imported by dll2 and so is missing classes definition.

So one would ususally use a definition like this.

#ifdef DLL1_EXPORTS
#define DLLEXPORT __declspec(dllexport)
#else
#define DLLEXPORT __declspec(dllimport)
#endif

class DLLEXPORT A
{
    //...

This construction makes sure, the dll1 definitions are exported when the header is used in dll1 and imported when used inside dll2 project. All you need is the macro DLL1_EXPORT to be defined when dll1 is compiled. The project settings for dll1 is usually a good place.

Another approach is to have 2 different headers, one for building dll1 and a second to be used together wit dll1's lib (without any __declspec(dllexport)).

Answer 2

For regular static class methods the declspec(dllexport) should be sufficient but in some cases (inline friend functions for example) you need to provide declspec(dllexport) for the function.

e.g.

#define DLLEXPORT __declspec(dllexport) 

class DLLEXPORT A {


     A();

     int somefunc();

     DLLEXPORT friend int operator==(const A &ws1, const A &ws2) 
            { /* some code */ } 

};   

Answer 3

The MSDN page about LNK2019 already gives plenty of examples why this error occurs. In order to trace down what exactly is going on, I recommend doing this:

1. Run undname on the symbol which the linker complains about to demangle the name (see Viewing Decorated Names for an example how to run undname).
2. Run dumpbin /EXPORTS (or use the graphical Dependency Walker) to get a list of all symbols exported by DLL1.

So now you have the demangled name of the symbol which the linker tries to find, and you have the list of symbols which are exported by DLL1. And the linker tells you that it cannot find the requested symbol in the list. Here are two ideas about what's going on:

1. You see that DLL1 has the demangled symbol in its export list, but not exactly the mangled name which the linker complains about. This can happen when the function you export is almost the same which the linker expects. It might be that you have a 'const' missing somewhere, or the calling convention is different.
2. You see that DLL1 doesn't export any symbol which looks like what the linker expects. This suggests that some __declspec(dllexport) is missing in the declarations of DLL1.

Answer 4

I recently had the same problem. The problem was a method signature void myMethod(const MyType&);with a parameter which I had forward-declared as class MyType;; however, the definition was a struct MyType{};.

As described in https://stackoverflow.com/a/40738415/71051 this can lead to linker issues with Visual-C++ - in my case the LNK2019.

Took me a while to resolve this, maybe this is of help for someone in the future.