Unsolved Qt libraries loading
-
I've never worked with such setup, perhaps I am wrong about it. Perhaps it will be enough to rename your Qt libraries, too? I doubt it, but it's definitely the easiest way to check.
The general instructions are here: docs.
And some config options are mentioned here, although namespace is not mentioned there. Use
configure -help
to get them all. -
To add - the directory search order for dlls is described here: Dynamic-Link Search Order. In essence what's next to the binary first, then system dir, current working directory and PATH environment variable in that order.
The main app will load its dependencies and if the plugin uses anything the exe already loaded it will share the same dll. If not the search order is the same for dll's dependencies.
All in all it's very risky to use two different sets of Qt libraries in your main app and the plugin. There's a lot that can go wrong so the best approach is to use one set of Qt dlls for the whole app (exe and dlls) like sierdzio said and put them next to the binary so they are picked up as first choice.
-
@Chris-Kawa said in Qt libraries loading:
The main app will load its dependencies and if the plugin uses anything the exe already loaded it will share the same dll. If not the search order is the same for dll's dependencies.
I agree with you but unfortunately the exe is not under my ownership .
Sorry if I ask again but it isn't clear to me this:
If the exe uses this own renamed dlls why it could be risky to me load official Qt5 dlls?
I try to explain better. The exe uses this own library, one or more additional plugins load official Qt5 dlls. (Each of them deploy the official Qt5 dlls) if the first plugin load Qt5 dlls and my second plugin uses the dlls loaded by the previous one why this could be risky? Both are using the official dlls. Right?An additiona question:
I read the suggested document to recompile Qt but this action requires a commercial license and I haven't. Do you have any other idea ? Link Qt statically? In this case which kind of license is required?
Thanks -
@Paola said in Qt libraries loading:
Qt but this action requires a commercial license
Compiling Qt does not require a commercial license.
-
@Paola In my plugin I've added QCoreApplication::addLibraryPath(mybinpath) Is it useful to prevent problem?
-
@sierdzio said in Qt libraries loading:
@Paola said in Qt libraries loading:
Qt but this action requires a commercial license
Compiling Qt does not require a commercial license.
Thanks I'm relieved, then the Step1 means that I should have commercial license only if I want to compile Commercial modules. Rights?
-
@Paola said in Qt libraries loading:
Compiling Qt does not require a commercial license.
Thanks I'm relieved, then the Step1 means that I should have commercial license only if I want to compile Commercial modules. Rights?
All modules in Qt are available under at least 2 licenses (and often more) - one commercial and at least one open source. If your work is compatible with open source licenses (usually LGPL, sometimes GPL) in modules you need, then you can use it. If your work does not satisfy FOSS licenses, you need the commercial one.
-
@sierdzio said in Qt libraries loading:
@Paola said in Qt libraries loading:
Compiling Qt does not require a commercial license.
Thanks I'm relieved, then the Step1 means that I should have commercial license only if I want to compile Commercial modules. Rights?
All modules in Qt are available under at least 2 licenses (and often more) - one commercial and at least one open source. If your work is compatible with open source licenses (usually LGPL, sometimes GPL) in modules you need, then you can use it. If your work does not satisfy FOSS licenses, you need the commercial one.
Thanks
-
@Paola said in Qt libraries loading:
why this could be risky?
There are multiple subtle potential problems. One of them is that Qt has some internal state held and you'll be getting multiple instances of it in possibly incompatible formats if versions of Qt differ enough. Same with things like size of structs, pointers allocated with one versions and freed with another. Also Qt dlls have additional dependencies like the C++ and compiler runtimes, which have their own restrictions and it's discouraged to mix them. Renaming dlls is also not a good idea. If I remember correctly some paths or file names are compiled into the dlls so you might have problems with that too e.g. one version loading a dependency from the other.
It's possible to avoid those issues if you're very careful but it's likely you'll get at least some of those issues at some point and they often manifest via very difficult to track and debug crashes at seemingly unrelated points.
So in short you're welcome to try, just be warned: there be dragons, scary ones. -
@Chris-Kawa
Thank you your clarification is very useful and I don't like dragons :)
Then I think that the suggestion "you can compile Qt on your own inside a custom namespace (Qt's configure script allows to specify a custom namespace)." wrote by @sierdzio is the correct solution.