Compiling a dll (TEMPLATE =LIB) with MSVC2012 leads to unresolved external symbol

[maitai]

Many thanks D_stranz for your helpful reply

In fact I had already more or less figured out how to configure Q_DECL_EXPORT and Q_DECL_IMPORT for the plugin. My problem is kind of opposite: I want my plugin to be able to use methods or classes that are inside the main application. That is where I am getting undefined externals with msvc, and not with gcc. I have tried to put Q_DECL_EXPORT or Q_DECL_IMPORT when declaring the classes in the main app that I want my plugin to be able to call, but that didn't work. Maybe that is not possible, as I said gcc is compiling but that does not prove it will be executable.... Of course I could add all the classes I need inside the plugin project but I will end-up with a plugin almost as big as the main application...

[anda_skoa]

When you say classes of the main app, do you mean you are building them only into the executable or do you have a proper "host API" library that the plugin links against?

Cheers,
_

[maitai]

Well, what I am trying to do is to build them only into the executable and then load the plugin at run-time only, using QPluginLoader. My understanding was that somehow the symbols resolution would take place at that moment. I can declare the plugin as static and then link it to my main application, but I would prefer to be able to deliver a new plugin without having to recompile/deliver the main application. Maybe that cannot be done because I am using main application symbols from within the plugin?

[anda_skoa]

Well, the plugin will need to resolve symbols for all code external to it, e.g. Qt's libraries. This of course also applies to your project libraries.

If you pass an instance of one of your classes to the plugin, it needs to have the header for compilation and the symbols for linking.

My guess is that you satisfy the former by having plugin and application code in the same tree, maybe as sub projects.

If that is true then you need to put all host API classes, or at least their interfaces, into a library that is linked by both plugins and application, just like both your plugin and your application linking with Qt.

Cheers,
_

P.S.: you can also get symbol hiding on Linux if you prefer fixing there. Look for QMAKE_CXXFLAGS_HIDESYMS in the qmake.conf files of your Qt installation

[maitai]

Thanks for your help,

So basically I need to have a shared library between my main application and the plugins...

Other solutions that crossed my mind:

Can I instead derived the classes I need from generic classes containing only pure virtual methods and use these generic classes in the plugins? In fact I need only 4 or 5 classes and around 30 methods from the main application, but if I need to build a shared library I'll probably need to put much more in it to since these classes are calling/using/instantiating many things...

Or maybe I can remove all these annoying classes from the plugins and use instead signals and slots to retrieve the information I need from the main app and also to trigger some action from it? For instance instead of doing object->getStatus() I would emit getObjectStatus() and get the reply in a slot... Sounds more complicated but maybe that would do the trick?

Thanks again

[d_stranz]

Can I instead derived the classes I need from generic classes containing only pure virtual methods and use these generic classes in the plugins?

In principle, possibly, but at some point you need to supply your DLL with concrete instances of classes derived from those pure virtual classes. Maybe you can do this with a signal / slot mechanism, but I think you are more likely to be successful if you build a static library (or non-plugin DLL) that is shared between the main app and the plugin DLL that contains the classes you want both of them to have access to. If you make it a non-plugin DLL that automatically gets loaded at startup, then you only need to link your plugin against the .LIB that MSVC builds for the DLL.

[maitai]

I have tested the idea of subclassing my main application classes with pure virtual classes, with a small example. That works wonderfully and I just need to declare in the virtual classes the methods I need. It works a bit like a reverse interface from the plugin to the main application. There is no reference to the real class in the plugin, it just uses the virtual one (just a .h file)

I will continue that way with the real stuff which is much more complicated than my small example and I'll keep you posted

Many thanks for your help

[d_stranz]

Yes, this will work. I presume that at some point in loading the plugin, you call some type of "initialize()" method and pass in a pointer to a concrete instance of the virtual class, right?

If you look at the Qt Creator architecture, the main application is pretty much just a plugin loader. All of the functionality of Creator is moved into plugin DLLs, one of which (Core) is required to be present. The other plugins ask Core to do things for them, through virtual interfaces. Your implementation basically merges Core aand the main app together.

[maitai]

Yes, this will work. I presume that at some point in loading the plugin, you call some type of "initialize()" method and pass in a pointer to a concrete instance of the virtual class, right?

Yes exactly. I load the plugin from my main widget (which is a MainWindow, derived from MainWindowInterface, itself derived from QMainWindow), and do something like
pluginLoader->instance()->init((MainWindowInterface *)this);

After that the plugin has a concrete instance of my widget, and can use whatever methods or even slots that are defined as virtual in MainWindowInterface.h. That way I don't need to link it against MainWindow's actual code.