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

[maitai]

Hello all,

I have a small project that I intend to use as a dynamic plugin. That compiles fine under qt_511/linux/gcc, but I cannot succeed to compile with qt_511/windows/msvc2012. The compiler issues a lot of errors with unresolved external symbol. These symbols and classes are actually defined in the main application, and the plugin just has access to the .h definitions. I believe it has nothing to do with the fact that this library is intended to be a plugin, since when I remove all plugin-related macros and such, I still get the same problem under msvc-2012 only (linux/gcc is still fine as far as the compilation goes). I have tried a lot to play with Q_DECL_EXPORT/Q_DECL_IMPORT and Q_CORE_EXPORT with no luck.

If I add "static" to the CONFIG, it compiles but this is not what I want: I don't want a .lib file I want a .dll

Any help in understanding why it compiles fine with gcc and not with msvc-2012 will be really appreciated,

Thanks

[d_stranz]

Your plugin project should have an include file like this:

// myplugin_global.h
#ifndef MYPLUGIN_GLOBAL_H
#define MYPLUGIN_GLOBAL_H
 
#include <QtCore/qglobal.h>
 
#ifdef MYPLUGIN_LIB
# define MYPLUGIN_EXPORT Q_DECL_EXPORT
#else
# define MYPLUGIN_EXPORT Q_DECL_IMPORT
#endif
 
#endif // MYPLUGIN_GLOBAL_H

// myplugin_global.h
#ifndef MYPLUGIN_GLOBAL_H
#define MYPLUGIN_GLOBAL_H

#include <QtCore/qglobal.h>

#ifdef MYPLUGIN_LIB
# define MYPLUGIN_EXPORT Q_DECL_EXPORT
#else
# define MYPLUGIN_EXPORT Q_DECL_IMPORT
#endif

#endif // MYPLUGIN_GLOBAL_H

To copy to clipboard, switch view to plain text mode 

and each of the classes that you want to export from your plugin DLL should be declared this way:

#ifndef MYPLUGIN_H
#define MYPLUGIN_H
 
#include <QObject>
#include <QtPlugin>
 
#include <IMyPlugin.h>  // defines pure virtual interfaces implemented by MyPlugin
 
#include "myplugin_global.h"
 
class MYPLUGIN_EXPORT MyPlugin
	:	public QObject
	,	public IMyPlugin  // the interface supported by your plugin class
{
	Q_OBJECT;
	Q_PLUGIN_METADATA( IID "com.MyCompany.IMyPlugin" );
	Q_INTERFACES( IMyPlugin );
 
        // ... constructor, destructor, and implementation of iMyPlugin virtual methods
};
 
#endif // MYPLUGIN_H

#ifndef MYPLUGIN_H
#define MYPLUGIN_H

#include <QObject>
#include <QtPlugin>

#include <IMyPlugin.h>  // defines pure virtual interfaces implemented by MyPlugin

#include "myplugin_global.h"

class MYPLUGIN_EXPORT MyPlugin
	:	public QObject
	,	public IMyPlugin  // the interface supported by your plugin class
{
	Q_OBJECT;
	Q_PLUGIN_METADATA( IID "com.MyCompany.IMyPlugin" );
	Q_INTERFACES( IMyPlugin );

        // ... constructor, destructor, and implementation of iMyPlugin virtual methods
};

#endif // MYPLUGIN_H

To copy to clipboard, switch view to plain text mode 

Such classes compile and link into a DLL just fine in MSVC2012 on my system. I did have the experience with undefined externals, but this appears to be a glitch in MSVC. If you do a clean rebuild, I think they go away. It's been a long time, so I don't remember exactly what I did - I remember there was some mis-configuration, but I use vcxproj files, not .pro files.

You might also check to make sure that "MYPLUGIN_LIB" is defined when compiling your DLL, and not defined when you link your DLL as an ordinary (not dynamically loaded) DLL (by linking to the corresponding .LIB that defines the entry points that will be resolved at runtime)

[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.