The most stubborn unresolved external ever.

Started by
9 comments, last by AnAss 15 years, 4 months ago
I have tried everything I know of on this bastard. Header:


#ifdef DLL_EXPORTS
#define DLL_API _declspec(dllexport)
#else
#define DLL_API _declspec(dllimport)
#endif

class DLL_API Class : public AnotherClass
{
   static int s_static;

public:
   static const int * Static() { return &s_static; }

   void NonStatic();
}; 
Cpp:

int Class::s_static = 10;

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
    GlobalFunctionInAnotherDll(Class::Static());
    return TRUE;
}

void Class::NonStatic()
{
}

This DLL builds fine. Another project attempts to use Class::Static(). It builds fine in debug mode, it has an unresolved external on the Class::s_static in release mode. In both builds, Class::NonStatic AND Class::Static() resolves just fine. I've tried: - Scouring the properties for each config a dozen times for differences, nothing. - Project dependencies are correct - putting _declspec(dllexport) on the definition of Class::s_static; - Searching the exp file for the decorated name (it is there) - Linking the client project directly to the export library - A few other things, none of which could explain it failing to resolve s_static while resolving Static() and NonStatic(). - Most importantly, I did dumpbin /exports on the DLL, and the symbol is there! I copied it, pasted it in a text file, then copied the compiler output and did a search just to make sure I wasn't miscounting an @ symbol or anything like that. It is identical. It is also in the .lib file. I've built about 15 DLLs in this project from scratch, and come across my fair share of these linker errors. Of all of the problems that I've had, none of them were this stubborn, and none of the fixes for any of them in the past I can remember will fix this one. Mainly, what could possibly cause this one symbol to fail to resolve, while the other symbols in the class resolve just fine? And that it appears in the DLL exports and lib exports?
Advertisement
Not sure, but have you tried moving the DLL_API macro from the class declaration to the declaration of the member functions instead?
Must be some kind of compiler setting if it works in debug but not release. It could be that for some reason, your compiler is stripping out s_static from the release build as it isn't used anywhere in the DLL. Try adding some code that does something with it. Just a thought.
What compiler are you using? I'm getting the same sort of problem using the Intel compiler, when I turn off optimization the problem goes away...
I am not sure about this, but your s_static member variable looks private. I don't know how you can access it like that without making it public.
Not 100% but should the static variable not have the export define as well; on its initialisation. Not sure if its even in the right place but u get the idea :p

int DLL_API Class::s_static = 10;
Innovation not reiterationIf at any point I look as if I know what I'm doing don't worry it was probably an accident.
If it's working in debug, but not release, it's likely that it's a project setting and your code is fine. You're sure that DLL_EXPORTS is defined in the preprocessor defines for release mode? What about the export library having the same name in the release mode as the debug mode? I've made both mistakes before.

cheers,

Bob

[size="3"]Halfway down the trail to Hell...
This probably isn't it, but you are certain you're declaring DLL_EXPORTS in both Debug and Release configurations, right?
f8k8/bluntman: I tried turning off strip unused symbols. Regardless, this should not be the problem because it IS used (by the call to GlobalFunctionInAnotherDll).

Sleek: It is accessed by Static() which is public.

Guthur: The right syntax is DLL_API int Class::s_static = 10;, and I tried that.

Scourage/Sneftel: I have checked this about 10 times, its there, and to verify it is working/no typoes, it is in the output of dumpbin /exports for BOTH the debug and release dll/lib.

Sure it's the same file? Search your entire computer for the LIB file, make sure there's only one, delete it, rebuild. Bizarre, not-in-either-half problems are often caused by file mismatches, IME.

This topic is closed to new replies.

Advertisement