If the target library itself, or at least its specification, is under your control, then you shouldn't be using QLibrary
- use the Qt plugin system instead. It doesn't require the call-via-pointer gymnastics otherwise needed.
If you insist on using a dlopen
-like mechanism, there is nothing C-specific about QLibrary
. The obvious limitation is that the library that you're trying to open must have been compiled with a C++ compiler that's ABI-compatible to the one you use to compile your own code. On Windows that really means using the same MSVC version.
Apart from that, you'll have to look up the mangled version of the symbol. Once you've done that, you can call the symbol using a function/method pointer that matches it. This won't work on constructors/destructors, by design. If you wish to create new instances of objects, you'll need a static factory method provided by the library.
If the library doesn't provide factory methods, you can implement a shim library that links to the target library by a generic name and does provide factory methods. You'll still need to call individual methods by function/method pointers.
- Create a temporary folder.
- Copy the shim library to the temporary folder.
- Copy the target library renamed to the generic name, into the temporary folder.
- Save the value of
LD_LIBRARY_PATH
environment variable.
- Prepend the temporary folder to
LD_LIBRARY_PATH
.
- Open/load the library.
- Restore the saved value of
LD_LIBRARY_PATH
.
Of course, you must have the header file for whatever interface the library exposes. It can't be, generally, reconstructed given just a dynamic library file - primarily because the mangled symbols don't have full structural information for the used types. For example, even if you can find a constructor for a given class, you won't know how big is the class instance (its sizeof
).