how to load a dynamic library on demand from a QT method

Qt Enthusiast

Can u guide how

Normally one can use plugins and interfaces and it removes the resolve part
but you are using plain shared lib, so not not sure what u need or dont nee

Qt Enthusiast

What is use of QLibrary::ResolveAllSymbolsHint

raven-worx

@Qt-Enthusiast said in how to load a dynamic library on demand from a QT method:

What is use of QLibrary::ResolveAllSymbolsHint

this just resolves all symbols at load time, as said in the docs.
But still you need a pointer to the function you want to call.

hskoglund

Hi, you can use a function pointer like this:

auto f = (void (*))(Tcl_Interp *) QLibrary("/path/to/libmy.so").resolve("My_Init");

f(&my_tcl_struct);     // calls your function

Qt Enthusiast

for each Call to Qt function I need to have a function pointer correct ?

hskoglund

Sure, but if you only call a function once, you don't need to save the pointer, just use it directly, say like this:

((void (*))(Tcl_Interp *) QLibrary("/path/to/libmy.so").resolve("My_Init"))(&my_tcl_struct);

Hope I got all the parentheses right :-)

Qt Enthusiast

after that can I call QT code dirrectlt

QTreewidget* tree = new QTreeWidget()..

Qt Enthusiast

I do not need to link the QT library in my QExecutable

kshegunov

@hskoglund
That's why I usually typedef the type locally, looks simpler (and since I despise auto I'm a happy man not using it):

typedef void (*MyInitPtr)(Tcl_Interp *);
MyInitPtr My_Init = reinterpret_cast<MyInitPtr>( QLibrary("/path/to/libmy.so").resolve("My_Init") );
if (My_Init)
    My_Init(&my_tcl_struct);

@Qt-Enthusiast

after that can I call QT code dirrectlt

No, and you won't be able to accomplish that with QLibrary, it's a bit more involved than resolving a simple C-linkage function.

Qt Enthusiast

Two questions

1 ) Do not need to link the QT library in my final Executable
2) also Can u write a sample application how will multiple calls to many Qt functions codes can be called after

typedef void (*MyInitPtr)(Tcl_Interp *);
MyInitPtr My_Init = reinterpret_cast<MyInitPtr>( QLibrary("/path/to/libmy.so").resolve("My_Init") );
if (My_Init)
My_Init(&my_tcl_struct);

kshegunov

@Qt-Enthusiast

Okay, @mrjj encouraged me to give you the full reasoning why those shenanigans are bad. Hence, I'm going to do so. Suppose you have a class MyClass with declaration in "myclass.h":

class MyClass
{
public:
    MyClass();
    ~MyClass();

    void myMethod(int);
}

and you want to call myMethod(int) of a newly created object of that class. But also suppose that class is compiled into a dynamic library myclasslib.so for all intents and purposes of this discussion. Suppose that the fully decorated symbols' names for the methods of this class are as follows:

MyClass::MyClass$constrDecoration for MyClass::MyClass
MyClass::MyClass$destrDecoration for MyClass::~MyClass
MyClass::MyClass$methodDecoration for MyClass::myMethod(int)

So this is how you can create an object, call it's constructor, call the method and finally call the destructor and free the allocated memory (code is not tested, but should be working in principle):

#include "myclass.h"

int main()
{
    MyClass * obj = reinterpret_cast<MyClass *>(::malloc(sizeof(MyClass))); // Allocate the object
    // Define two types for a pointer to method with and without an argument
    typedef void (MyClass::*MyMethodNoArgPtr)();
    typedef void (MyClass::*MyMethodIntArgPtr)(int);

    // Get the library
    QLibrary myLib("myclasslib.so"); //< This is the binary, in which the code for `MyClass` is compiled
    // Resolve the constructor, destructor and myMethod (notice the fully decorated symbols' names)
    MyMethodNoArgPtr _construct = reinterpret_cast<MyMethodNoArgPtr>(myLib.resolve("MyClass::MyClass$constrDecoration"));
    MyMethodNoArgPtr _destruct = reinterpret_cast<MyMethodNoArgPtr>(myLib.resolve("MyClass::MyClass$destrDecoration"));
    MyMethodIntArgPtr myMethod  = reinterpret_cast<MyMethodIntArgPtr>(myLib.resolve("MyClass::MyClass$methodDecoration"));

    // Wow, now we can actually call what we need
    (obj->*_construct)(); //< Call the constructor
    (obj->*myMethod)(10); //< Call MyClass::myMethod(10)
    (obj->*_destruct)()   //< Call the destructor

    // We can free the memory now
    ::free(obj);
    return 0;
}

This all would be equivalent to:

#include "myclass.h"

int main()
{
    MyClass * obj = new MyClass();
    obj->myMethod(10);
    delete obj;

    return 0;
}

if we were to leave the loader to do what it's supposed to do!

Oh, and by the way, this gets even more complicated when the objects have virtual tables (which QObject derived classes do).

Two questions

Do not need to link the QT library in my final Executable

If you use Qt, you do.

also Can u write a sample application how will multiple calls to many Qt functions codes can be called after

I don't understand the question. What multiple calls to which many Qt functions do you have in mind?

Qt Enthusiast

because it application as big appilcation of Qt code

kshegunov

@Qt-Enthusiast
I don't follow.

Qt Enthusiast

for example

I have GUI application which has 1 lacs of QT code

for example

   QTreeWidget *w  = new QTreeWidget;
  QLabel * w = new QLablep

    class myTreeView:public QTreView {
     Q_Object
   };

My question is If my load the dynamic library like

is there direct way algorithm is

void loadSharedObject() {  
    //load the
    // Call the function names directly
    // no extra code for resolving the function /symbols names   
    // for example  
     fun1()
     fun2()
 }

Qt Enthusiast

My question is If my load the dynamic library like

is there direct way algorithm is

void loadSharedObject() {
//load the
// Call the function names directly
// no extra code for resolving the function /symbols names
// for example
fun1()
fun2()
}

because the dyanamic libary in my is QLibrary

kshegunov

@Qt-Enthusiast said in how to load a dynamic library on demand from a QT method:

// Call the function names directly
// no extra code for resolving the function /symbols names
// for example

No there isn't a way to do that. This is what linkers and loaders were created for. You can't leave a bunch of unresolved symbols that are supposed to be explicitly loaded at runtime, it just doesn't work that way.