Hello,
I am writing a plugin, which register it self with main program when its starter function is called.
the code snip below is taken from the plugin project. I include main program's required headers in order to use its functions to register new plugin with main. But I get this error for each function I used from main
dx11RenderPlugin.obj : error LNK2019: unresolved external symbol "public: void __thiscall amz::Main::initializePlugin(class amz::Plugin *)
#include "amzMain.h"
// Plugin it self
Dx11RenderPlugin* plugin;
extern "C" _AmzExport void dllStartPlugin(void)
{
plugin = new Dx11RenderPlugin();
// add it to the main
Main::getSingleton().initializePlugin(plugin);
}
extern "C" _AmzExport void dllStopPlugin(void)
{
Main::getSingleton().uninitializePlugin(plugin);
delete plugin;
}
[Edited by - afraidofdark on August 28, 2010 4:03:55 PM]
extern "C" unresolved external symbol
That error means the linker couldn't find the implementation for amz::Main::initializePlugin, which either needs to come from code directly compiled into your plug-in or from a library you link against. A better approach might be to have the main application register the plug-ins, rather than the having the plug-ins register themselves when a function is called on them (which sounds like it may being called from the application anyway). This way you don't have any dependencies on application code in your plug-in, and can instead just implement an interface from a header file and let the application do all the work.
Be careful, your application and your DLL may actually have different instances of your singleton.
Author
Quote:Original post by SiCrane
Be careful, your application and your DLL may actually have different instances of your singleton.
exactly as you told, the dll creates a new instance of the singleton and register the newly created plugin with that instance. I am thinking of returning a void pointer of the created plugin. Than registering it inside the application.
Also as Zipster told, doing registering thing in the application will also seperate the dll and application
thank you for your suggestions.
Author
I figured out that, each plug-in has something to do with main, but I have a general plug-in load method in main class, so registering inside the plug-in is actually become a benefit because I do specific operation in the install method of the plug-in than add it to the main.
Like this
void D3D9Plugin::install() {
HINSTANCE hInst = GetModuleHandle( "Dx11RenderPlugin.dll" );
mRenderSystem = new Dx11RenderSystem( hInst );
// Register the render system
// this kind of operation should be done in the plug-in, and they
// differ from plug-in to plug-in
Main::getSingleton().addRenderSystem( mRenderSystem );
}
so how can I guaranty that "Main::getSingleton()." this line returns the same instance that is created in the application ?
Like this
void D3D9Plugin::install() {
HINSTANCE hInst = GetModuleHandle( "Dx11RenderPlugin.dll" );
mRenderSystem = new Dx11RenderSystem( hInst );
// Register the render system
// this kind of operation should be done in the plug-in, and they
// differ from plug-in to plug-in
Main::getSingleton().addRenderSystem( mRenderSystem );
}
so how can I guaranty that "Main::getSingleton()." this line returns the same instance that is created in the application ?
Author
it seems I need to export Main class aswell
[Edited by - afraidofdark on August 31, 2010 5:13:29 AM]
[Edited by - afraidofdark on August 31, 2010 5:13:29 AM]
There are ways of implementing your plug-in system that can eliminate the circular dependency between the plug-ins and the application. The first approach (and best IMHO) is to re-factor your interface so that the plug-ins don't need a Main instance and can rely entirely on common low-level libraries. Instead of doing Main::getInstance().addRenderSystem(...), pass the plug-in a IRenderSystemInterface pointer they can use instead. The same goes for other subsystems the plug-ins need access too. Whenever you think that you need Main, think a little more about what it is you actually want to do and how you can achieve it through common interfaces, low-level libraries, etc., anything that both plug-ins and Main will know about without depending on each other.
The second approach is to the move the plug-in system to a library below the application, and have the plug-ins be on the same level as the application (in other words, both the plug-ins and Main depend on your general plug-in system, but they don't depend on each other). If you make your plug-in system into a DLL, any plug-ins you load at runtime alongside the application will share the same code, and thus the same instance of anything in the plug-in system module.
The second approach is to the move the plug-in system to a library below the application, and have the plug-ins be on the same level as the application (in other words, both the plug-ins and Main depend on your general plug-in system, but they don't depend on each other). If you make your plug-in system into a DLL, any plug-ins you load at runtime alongside the application will share the same code, and thus the same instance of anything in the plug-in system module.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
