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 __declspec(dllexport)) in order to export the class inside dll1 (for dll2 usage).
2. I have another DLL project dll2 that uses dll1's functionality. I specified the *.dll1.lib file path inside the linker input in the project's properties and gave reference to dll1 *.h files. At this point everything needs to work fine. (I think..)
3. When compiling dll2, I get a LNK2019 error that tells me can't find some method referenced in dll1. (This method in dll1 is a static method.)

Why do I get this error?

Answer 1

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 2

maybe you need to recompile dll1?

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

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)).