views:

572

answers:

3

I have a DLL which contains a class with static members. I use __declspec(dllexport) in order to make use of this class's methods. But when I link it to another project and try to compile it, I get "unresolved external symbol" errors for the static data.

e.g. In DLL, Test.h

class __declspec(dllexport) Test{
protected:
    static int d;
public:
    static void m(){int x = a;}
}

In DLL, Test.cpp

#include "Test.h"

int Test::d;

In the application which uses Test, I call m().

I also tried using __declspec(dllexport) for each method separately but I still get the same link errors for the static members.

If I check the DLL (the .lib) using dumpbin, I could see that the symbols have been exported.

For instance, the app gives the following error at link time:

1>Main.obj : error LNK2001: unresolved external symbol "protected: static int CalcEngine::i_MatrixRow" (?i_MatrixRow@CalcEngine@@1HA)

But the dumpbin of the .lib contains:

Version      : 0
  Machine      : 14C (x86)
  TimeDateStamp: 4BA3611A Fri Mar 19 17:03:46 2010
  SizeOfData   : 0000002C
  DLL name     : CalcEngine.dll
  Symbol name  : ?i_MatrixRow@CalcEngine@@1HA (protected: static int CalcEngine::i_MatrixRow)
  Type         : data
  Name type    : name
  Hint         : 31
  Name         : ?i_MatrixRow@CalcEngine@@1HA

I can't figure out how to solve this. What am I doing wrong? How can I get over these errors?

P.S. The code was originally developed for Linux and the .so/binary combination works without a problem

EDIT: In the given case, the static variables are not directly referred by the application but the method is inlined since it's in the header. I was able to resolve the link errors by moving the methods to the .cpp file.

+5  A: 

My guess is that the class which uses the DLL should see dllimport instead of dllexport in the header. If I am correct, this can typically be achieved by defining a preprocessor macro like:

#ifdef EXPORTING
#define DECLSPEC __declspec(dllexport)
#else
#define DECLSPEC __declspec(dllimport)
#endif

and then use it in the class declaration:

class DECLSPEC Test{
protected:
    static int d;
public:
    static void m(){}
}

So that in Test.cpp (or wherever it makes sense in your DLL project) you can specify that you are exporting so that it will be exported with dllexport:

#define EXPORTING
#include "Test.h"

int Test::d;

while the other project, which does not define EXPORTING, will see dllimport.

Does it make sense?

xqib-team
I thought dllimport was optional. I read somewhere that it was a mechanism to assist the linker and compiler to perform better optimization, hence increasing performance. Correct me if I'm wrong since my experience in this area is limited
Gayan
Yes, I also read that dllimport is optional. My understanding is that you can omit it, however dllexport should not be there for the application importing the dll: otherwise the compiler thinks it is exported by the application, looks for the corresponding definition, which does not exist, and this produces the error message.
xqib-team
+3  A: 

In this thread at cprogramming.com it is suggested that a static variable is local to the dll and not exported.

Summary of discussion below

The static member is not accessed directly by code in the calling application, only through member functions of the class in the dll. However there are several inline functions accessing the static member. Those functions will be inline expanded into the calling applications code makeing the calling application access the static member directly. That will violate the finding referenced above that static variables are local to the dll and cannot be referenced from the calling application.

Anders Abel
Yes I came across that (I've been trying to solve this for half a day now). But the given solutions do not apply to my case because I don't use the static members defined in the dll, in my application. They are hidden and are only used by local methods.
Gayan
Are there any inline methods accessing the static member? In that case the inline expanded code will be put in your application, directly accessing the static member.
Anders Abel
Yes!! I've written most of the methods in the header (bad practice.. I know) so think that's the case here
Gayan
Try moving all method bodies that uses the static member into .cpp-files which are compiled into the dll and cannot be inlined in the application, that will probably make it.
Anders Abel
After a lot of work I was able to get the executable to compile. I had to move a lot of methods from .h to .cpp files. This doesn't explain why the exported symbols were reported as being unresolved.
Gayan
I'm a bit hesitant to set this as the answer because in the linked answer, it's shown that symbols of static members "can" be exported. Two instances are created for the app and the dll but the symbol is not given as being "unresolved", which is what happened in my case. Please correct the post and I'll accept it.
Gayan
+1  A: 

With Windows DLLs, there is a specific distinction between __declspec(dllexport) vs __declspec(dllimport), dllexport should be used when compiling the DLL, dllimport should be used when compiling programs that link to this DLL. The standard way of defining this would be with a macro.

The following is the visual studio example:

// The following ifdef block is the standard way of creating macros which make exporting 
// from a DLL simpler. All files within this DLL are compiled with the DLL_EXPORTS
// symbol defined on the command line. this symbol should not be defined on any project
// that uses this DLL. This way any other project whose source files include this file see 
// DLL_API functions as being imported from a DLL, whereas this DLL sees symbols
// defined with this macro as being exported.
#ifdef DLL_EXPORTS
#define DLL_API __declspec(dllexport)
#else
#define DLL_API __declspec(dllimport)
#endif
Ramon Zarazua