Unsolved Qt libraries loading
-
Hi,
I've some doubts regarding the mechanism of Qt libraries loading.
The scenario is:
I've two different Qt plugins (shared Qt libraries) and both have in their bin folder the libraries Qt5Core.dll, Qt5Gui.dll, Qt5Widgets.dll and the folders platform, imageformats and style.
An external exe application loads both libraries.
The question is:
Does the second library use the Qt5 loaded by the previous one or use its own libraries?
What's the mechanism? What's the correct way to deploy the plugins in order to be sure that each one uses the own Qt5 libraries?
Thanks in advance for your help.
Paola -
The parent application should have Qt libraries. Plugins do not need them, they just use what is already there in memory. So, all plugins share the same Qt version and should be compiled using the same Qt version.
If your parent application is not a Qt app, the libraries will likely clash. To avoid it, you can compile Qt on your own inside a custom namespace (Qt's configure script allows to specify a custom namespace).
-
@sierdzio
The parent exe application is a mixed MFC/Qt application , it's an external application not under my ownership and the Qt5 libraries inside its bin folder are renamed.
My plugins are loaded by this application , this is the reason why I put inside bin folder my own Qt5 dlls. Then your suggestion is to recompile Qt by myself?
Please could you send me a link where I can read some additional info about this procedure?
Thanks
Paola -
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 -helpto 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.
