tags:

views:

84

answers:

3

I have a rather big Core project that I'm working with, I'm attempting to adapt it to use a DLL Engine I've built, I'm getting a bunch of errors like:

unresolved external symbol "private: static class

When including some of the headers from the Core in the DLL, the class is exported via __declspec(dllexport) but any header with static members throws out a crapload of errors regarding the static members.

This is a rather big project, I can't exactly run around removing every static class member I see, is there anyway around this kind of thing?

A basic example of a class that's being imported:

class __declspec(dllexport) MyClass
{
    public:
        static bool m_someVar;
}

For clarity sake I'd just like to address that m_someVar is defined/declared (forget the term) in the classes implementation file

A: 

Maybe a silly question but are you defining it somewhere? Your definition would look something like:

bool MyClass::m_someVar = false;
Yaur
Yes, this is done in the implementation file for the class.
Undawned
+1  A: 

Using your snippet and running Dumpbin.exe /exports on the DLL produces this output:

1    0 0001107D ??4MyClass@@QAEAAV0@ABV0@@Z = @ILT+120(??4MyClass@@QAEAAV0@ABV0@@Z)
2    1 00017000 ?m_someVar@MyClass@@2_NA = ?m_someVar@MyClass@@2_NA (public: static bool MyClass::m_someVar)

Note how the export for the static member is there but has a subtly different name from yours. If I run your export name through undname.exe, I get:

Undecoration of :- "?m_someVare@MyClass@@0EA"
is :- "private: static unsigned char MyClass::m_someVare"

Note the difference. You've got an evil macro in your target project. Fix your problem by adding this to the header file:

#undef bool

This might have some side-effects :)

Hans Passant
Not really sure I follow, the macro used in my project is basically SOME_DLL_EXPORT __declspec(dllexport)
Undawned
@Undawned: no, it is a macro used in the target project. Look for "#define bool unsigned char" in one of the header files. That macro screws up your class declaration.
Hans Passant
+2  A: 

When you compile the Core you want these functions to be dllexport; However, when you compile the DLL, you want them to be dllimport. In your case, you're always defining them as dllexport, thus when you link the DLL it complains that you've declared a function (and even said you'd export it) without ever defining it.

The solution is simple. Instead of manually __declspecing, create a macro based on whether you're the Core or the DLL:

#ifndef I_AM_A_DLL
#define EXPORT __declspec(dllexport)
#define IMPORT __declspec(dllimport)
#else
#define EXPORT __declspec(dllimport)
#define IMPORT __declspec(dllexport)
#endif

Use EXPORT for functions in the Core and IMPORT for functions in external DLLs:

class EXPORT MyClass
{
    public:
        static bool m_someVar;
}
Spidey