Plugin and base class constructor - c++

Question

In a Qt application I declare a base class:
class Base:
public QObject {
Q_OBJECT
public:
Base();
virtual ~Base();
virtual void doSomething();
};
Both the c-tor/d-tor and doSomething() have default implementations in a separate source file.
Furthermore, I provide an abstract interface to implement Qt's plugin scheme, like in the Echo Plugin Example.
class Interface {
public:
virtual ~Interface() {}
virtual Base *create() = 0;
};
#define Interface_iid "blag"
Q_DECLARE_INTERFACE(Interface, Interface_iid)
In a plugin that resides in a shared library, libPlugin.so I derive from this base class to provide custom implementations:
class Special:
public Base {
Q_OBJECT
public:
Special() { /* Implementation */ }
void doSomething() { /* Implementation */ }
};
Finally I also implement the plugin interface:
class Q_DECL_EXPORT Plugin:
public QObject,
public Interface {
Q_OBJECT
Q_PLUGIN_METADATA(IID Interface_iid)
Q_INTERFACES(Interface)
public:
Base *create() {
return new Special();
}
};
Now I can load this plugin via QPluginLoader and obtain access to its core object, which correctly identifies itself being a Plugin. But when I try to ThePlugin::create() the Special object, I get a linkage error:
symbol lookup error: libPlugin.so: undefined symbol: _ZN4BaseC2Ev
Beneath the name mangling, I suppose this refers to the Base::Base c-tor that is needed when constructing the derived Special object.
I'm tempted to compare to, e.g. a QStylePlugin: It basically does the same, returning some QStyle-derived class via an abstract interface. Please refer to the Style Plugin Example. Yet I guess the difference is that in the case of the style plugin, both the application (that provides the custom style plugin) and the style plugin itself are linked against the common Qt library that provides, e.g. the c-tors.
How could I resolve this?
What happens if link time optimization removes the c-tors because it cannot know they're needed by plugins?
Linking issue
When compiling and linking the plugin, the Base:Base() class' c-tor as well as the Base::doSomething() come out as unresolved symbol. The c-tor is called by the Special::Special() c-tor and cannot be resolved, of course. The other one is a virtual method
When compiling the application itself, it contains the implementations of the base class' methods. Obviously, they are not linked together when the plugin is loaded.
SSCCE
/********** Interface.h */
#ifndef INTERFACE_H
#define INTERFACE_H
#include <QtPlugin>
#include "Base.h"
class Interface {
public:
virtual ~Interface() { }
virtual Base *createWorker() = 0;
};
#define Interface_iid "blag"
Q_DECLARE_INTERFACE(Interface, Interface_iid)
#endif
/********** App.pro */
QT += core
TARGET = App
TEMPLATE = app
SOURCES += \
Base.cpp \
App.cpp
HEADERS += \
Base.h \
Interface.h \
/********** Base.h */
#ifndef BASE_H
#define BASE_H
#include <QObject>
class Base:
public QObject {
Q_OBJECT
public:
Base();
virtual ~Base();
virtual void doSomething();
};
#endif
/********** Base.cpp */
#include "Base.h"
Base::Base():
QObject() {
}
Base::~Base() { }
void Base::doSomething() { }
/********** App.cpp */
#include "Interface.h"
#include <QCoreApplication>
#include <QPluginLoader>
#include <QDebug>
int main(int argc, char *argv[]) {
QCoreApplication a(argc, argv);
QPluginLoader l("libPlugin.so");
qDebug() << l.load();
qDebug() << l.errorString();
return a.exec();
}
/********** Plugin.pro */
TARGET = Plugin
CONFIG += plugin
TEMPLATE = lib
SOURCES += \
Plugin.cpp \
Special.cpp \
HEADERS += \
Plugin.h \
Special.h \
Interface.h \
Base.h
/********** Special.h */
#ifndef SPECIAL_H
#define SPECIAL_H
#include <QObject>
#include "Base.h"
class Special:
public Base {
Q_OBJECT
public:
Special();
void doSomething();
};
#endif
/********** Special.cpp */
#include "Special.h"
Special::Special():
Base() {
}
void Special::doSomething() { }
/********** Plugin.h */
#ifndef PLUGIN_H
#define PLUGIN_H
#include <QObject>
#include "Interface.h"
class Q_DECL_EXPORT Plugin:
public QObject,
public Interface {
Q_OBJECT
Q_PLUGIN_METADATA(IID Interface_iid)
Q_INTERFACES(Interface)
public:
Base *createWorker();
};
#endif
/********** Plugin.cpp */
#include "Plugin.h"
#include "Special.h"
Base *Plugin::createWorker() {
return new Special();
}
Build:
# Separate files
qmake Plugin.pro && make
qmake App.pro && make
./App

Answer 1

I think I found what is wrong.
The construction I'd like to have linked is as follows:
A host application providing a base class with implementations
A plugin shared library that inherits from that base and re-implements some methods and/or accesses the base class' members
This basically boils down to the following in plain C:
A host application, providing some symbols
A plugin shared library, providing some more symbols and wanting to use some of the host's symbols
However, there is no generic way to achieve the latter.
A host can link against a library to use its functionality. That means the host gets method stubs that are dynamically resolved into against library once the host itself and the library are loaded. Contract between library and host may be some header file with declarations (not definitions).
When a library is dynamically loaded into a host's memory, symbols in the library in turn are not resolved against the host, though. Instead they stay unresolved.
This is exactly what I am seeing here. I tried to resolve the base class' functionality (that I did not implement in the plugin) against the host application that wants to load the plugin. Does-not-work.
This is that -rdynamic is for on ELF, refer to this post.