DLL Problem (Linker)

Started by
6 comments, last by chollida1 18 years, 9 months ago
I'm returning a pointer to an API that I have housed inside a DLL, and I'm pretty sure (I've done this a few times before) that I have everything coded right. But when I go to compile the program that will call the DLL, I'm getting a linker error about the deconstructor of the API. Here's the code and the error:

  if( !cmdLine.find("noupdate"))
  {
	  #ifdef _WIN32
		// why does windows always have to be different?
		if(HINSTANCE h=LoadLibrary("surveNET.dll"))
	    {
			typedef ISurveAPI* (*EXPORTAPI) ();
			EXPORTAPI pfnExport;

			if( !(pfnExport = (EXPORTAPI) GetProcAddress(h,"ExportAPI")) )
			{
				::MessageBoxA(NULL,"Failed loading surveNET.dll; please check your installation.\nec0",
					"Error",MB_OK|MB_ICONSTOP);
				return -1;
			}

			shared_ptr<ISurveAPI> pSurve = shared_ptr<ISurveAPI> ( pfnExport() );
			::FreeLibrary(h);
		}	
		else
	    {
			::MessageBoxA(NULL,"Failed loading surveNET.dll; please check your installation.\nec1",
				"Error", MB_OK|MB_ICONSTOP);
			return -1;
		}
	  #endif
	  return -1;
  }




main.obj : error LNK2019: unresolved external symbol "public: __thiscall ISurveAPI::~ISurveAPI(void)" (??1ISurveAPI@@QAE@XZ) referenced in function "public: void * __thiscall ISurveAPI::`scalar deleting destructor'(unsigned int)" (??_GISurveAPI@@QAEPAXI@Z)
../../bin/launch.exe : fatal error LNK1120: 1 unresolved externals


I know I'm probably missing something blatently stupid. But here's also the header file that is being used for both the DLl complication and the inclusion for the library in the main program.

class ISurveAPI
{
	public:
		// constructor/destructor
		ISurveAPI(void);
		ISurveAPI(const ISurveAPI&);
		~ISurveAPI(void);
};



-John "bKT" Bellone [homepage] [[email=j.bellone@flipsidesoftware.com]email[/email]]
Advertisement
change the line of the destructor into this:
~ISurveAPI(void) {};
before, you only had the declaration of the destructor. Now it also has the body (which does nothing).
Well, it does have a body, inside of the DLL.
-John "bKT" Bellone [homepage] [[email=j.bellone@flipsidesoftware.com]email[/email]]
But maybe the linker doesn't know that it is in the dll. Maybe you should use GetProcAddress on that function too and somehow tell the linker to use it.
But that would besides the whole point of exporting a class from a DLL. I should only have to do it once, and once only. Its only calling it because the shared_ptr falls out of scope, and the constructor is called within the DLL itself.
-John "bKT" Bellone [homepage] [[email=j.bellone@flipsidesoftware.com]email[/email]]
The linker needs the definition for that class, or more specifically the desctr. You need to
a) include the class definition in your main app/calling code
b) statically link to the dll

You may have never run into this before as usually you just call getprocaddress on a method that uses data taht the linker knows about.

If you don't let the linker know where teh definition is then how do you expect it to link:)

Cheers
Chris
I want to be able to use the DLL as a library through more than one code, why should I need to statically link the library each and every time I compile? There isn't a way to just export the class instance from the DLL?
-John "bKT" Bellone [homepage] [[email=j.bellone@flipsidesoftware.com]email[/email]]
there is but the linker needs the definition so it needs to be there at link time. hencethe need to have the dll's linker lib. that doesn't mean you can't useit as a dll, you just need to includeits linking lib.

cheers
chris
CheersChris

This topic is closed to new replies.

Advertisement