PDA

View Full Version : creating a dylib for a plugin with external classes



themolecule
21st August 2007, 06:57
I am able to create a plugin interface and link it, and the pluginLoader likes it, but if I try to include any classes from my main app, it won't link.

I would really like something like:




#include <C.h>

class A : public AInterface
{
public:
C *instance() { return new B(); }
};

class B : public C
{
B() {}
};

Q_EXPORT_PLUGIN2(app_A, A)


but I cannot figure out a way to get C.o to link when I create the dylib. It doesn't seem to make sense to add a LIBS line to the .pro that points to the .o file in:

[objectsdir]/Release/*build/Objects-normal/i386/C.o

because it doesn't feel right -- if I change machines, OSs, or distros it will break.

How do I get this link to work?

wysota
19th September 2007, 11:59
There are two ways of doing it. The less proper but easier way is to ask your compiler to allow dynamically loaded objects to resolve their symbols using the main application. For GCC it is done by adding a linker flag (I don't remember now what exactly). The other solution (preferred) is to export all the symbols you may want to use from the plugin into a separate library and link both the application and the plugin against the library.

themolecule
20th July 2008, 21:03
Any idea what flag this is?

Do I add it in the .pro or do I need to do something in the xcode project preferences?

wysota
21st July 2008, 11:15
The flag is -rdynamic, as far as I remember. You have to pass it to the linker in whatever way you see fit.

themolecule
23rd July 2008, 15:22
On osx, the .pro settings seem to be

QMAKE_LFLAGS += "-undefined"
QMAKE_LFLAGS += "dynamic_lookup"

but I never could get the symbols to be resolved from the main app. I think another flag in the main app would expose the symbols to make the dynamic lookup succeed.

Either way, the preferred solution you mentioned works! Thanks!