QPlugin failing to load
-
I am trying to use QPlugin to load my .so files. However, at load time (of my Poodle .so) I get this error:
undefined symbol: _ZN15Dog_Base16staticMetaObjectE)"
My relevant classes are: Animal_Base, which is the ancestor of Dog_Base, which is the ancestor of Poodle. Animal_Base inherits QObject, and all three of the above have the Q_OBJECT macro in them.
I have read countless posts about ensuring MOC runs, etc. I have followed all the guides/examples I can find, rerun qmake and cleaned out build dirs. However, I'm wondering if I'm not meeting a prerequisite to use QPlugIn. In particular:
My base class is NOT just an interface, it has a number of methods that are defined, some are virtual, and some are pure virtual. Is that a factor?
Is this cause of my problem? Must the class X reference by Q_DECLARE_INTERFACE(X) contain ONLY pure virtual methods? If so, does that mean I must use QLibrary instead?
I tried loading the .so using QLibary.load and get the same error
-
@ocgltd what is the issue with an abstract class ?
Building a library has nothing to do with using or not abstract classes.
However, building a plugin does. The interface which defines the plugin API is an abstract class yes. How would you implement a plugin without knowing what to implement ?
@SGaist Well I solved it...for anyone else interested.
Although my poodle.so compiled fine, I had not linked in the Dog_Base and Animal_Base classes to the .so. Again - NO error on compilation. But, when I tried to load the poodle.so it could not find the ctor for the base class - because it was not linked in to the library's .so
Very strange error...but solved!
-
Hi,
Is Animal_Base the interface class as well ?
If so, that is the main issue, your plugins should inherit from QObject and the interface.See here
@SGaist Animal_Base has a mix of defined methods, virtual methods, and pure virtual. Dog_Base just declares a couple more methods, and overrides a virtual method.
However, trying to load the .so with QLibrary.load causes the exact same problem. So are you saying that any .so (that is a class) must derive from an interface??
This is my first attempt at creating a .so file, so I'm new to all of this. I just can't figure out why derivation from an interface is important.
-
@SGaist Animal_Base has a mix of defined methods, virtual methods, and pure virtual. Dog_Base just declares a couple more methods, and overrides a virtual method.
However, trying to load the .so with QLibrary.load causes the exact same problem. So are you saying that any .so (that is a class) must derive from an interface??
This is my first attempt at creating a .so file, so I'm new to all of this. I just can't figure out why derivation from an interface is important.
The concept of a plugin is to have an interface which defines the common set of methods usually as pure virtual in a dynamic library.
Then each plugin implements that interface and links to that library.
-
The concept of a plugin is to have an interface which defines the common set of methods usually as pure virtual in a dynamic library.
Then each plugin implements that interface and links to that library.
@SGaist To keep life simple (while I'm learning) I'll switch to QLibrary to load my .so
But the error occurs with QLibrary.load too. Can I fix this error without making the base class abstract? It just seems weird that every .so implementation must be derived from an abstract class
-
Did you change the interface class as shown in the documentation ?
-
@SGaist I did not want to use an interface class (assuming that means the ancestor must be abstract). I read the QLibrary & Shared Libary pages, but did not see anywhere that the base class must be abstract.
Aside from that, I think my class follows the documentation. I've also been following this StackOverflow post for clues.
I've been going in circles for 5 hours on this one. I must be missing some concept.
-
@SGaist I did not want to use an interface class (assuming that means the ancestor must be abstract). I read the QLibrary & Shared Libary pages, but did not see anywhere that the base class must be abstract.
Aside from that, I think my class follows the documentation. I've also been following this StackOverflow post for clues.
I've been going in circles for 5 hours on this one. I must be missing some concept.
@ocgltd a plugin has a different purpose than a shared library.
Please check again the documentation about the plugins I linked above. There are several examples that shows how to implement them for extending a Qt application.
-
@ocgltd a plugin has a different purpose than a shared library.
Please check again the documentation about the plugins I linked above. There are several examples that shows how to implement them for extending a Qt application.
@SGaist I've read the page many times, and in their example "FilterInterface" (the base class) is abstract.
That's why I abandoned QPlugin and just want to load the .so with QLibrary. I don't want to use an abstract base class. (Unless you are saying an SO class must be based on an abstract class??)
However, I think that's where I'm getting stuck. I'm missing some important concept. I confirmed with 'nm' that the symbol mentioned in the runtime error is NOT in the moc_X.cpp file. Why?
I appreciate the help!
-
@SGaist I've read the page many times, and in their example "FilterInterface" (the base class) is abstract.
That's why I abandoned QPlugin and just want to load the .so with QLibrary. I don't want to use an abstract base class. (Unless you are saying an SO class must be based on an abstract class??)
However, I think that's where I'm getting stuck. I'm missing some important concept. I confirmed with 'nm' that the symbol mentioned in the runtime error is NOT in the moc_X.cpp file. Why?
I appreciate the help!
@ocgltd what is the issue with an abstract class ?
Building a library has nothing to do with using or not abstract classes.
However, building a plugin does. The interface which defines the plugin API is an abstract class yes. How would you implement a plugin without knowing what to implement ?
-
@ocgltd what is the issue with an abstract class ?
Building a library has nothing to do with using or not abstract classes.
However, building a plugin does. The interface which defines the plugin API is an abstract class yes. How would you implement a plugin without knowing what to implement ?
@SGaist Well I solved it...for anyone else interested.
Although my poodle.so compiled fine, I had not linked in the Dog_Base and Animal_Base classes to the .so. Again - NO error on compilation. But, when I tried to load the poodle.so it could not find the ctor for the base class - because it was not linked in to the library's .so
Very strange error...but solved!
-
O ocgltd has marked this topic as solved on