Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
why does my program find dll's it is not suposed to find?
Normaly people ask why it cant find dll's, but i also want to understand why it find dll's.
When i run my program in dependency walker it points to dll's that are not deliverd (but should) with my program. And finds these dll in the qt instalation directory ( example: "c:\qt\5.7\msvc2015_64\plugins\imageformats\QGIF.DLL" ).
If i rename the qt directory it wont run properly, so it surly used the dll's in that folder.
my program is installed in 'C:\Program Files\myProgram" and and started from Dependency walker.
if i type "path" or "set" in the command promp there is nothing pointing to the qt instalation dir.
what is pointing to "c:\qt\5.7\msvc2015_64" ?
marievin last edited by
I think that you don't see the entire content of your environment variables using the path or set commands in a command prompt.
Please look at your environment variables in the Windows GUI : (On Windows 10) type Windows Key + Pause -> Advanced System Parameters -> Environment Variables
On Windows, the documentation explains how the DLL are searched.
Hope this will help
@Koen-de-Gruijter Because Qt consists of modules and plug-ins. Some modules have dependencies to other modules or plug-ins.
From your example: plugins\imageformats\QGIF.DLL is needed by QtGui to be able to handle GIF images. Even if you do not use GIF images in your application QtGui still have that dependency (but can be used without QGIF.DLL as long as you do not try to use GIF images).
@marievin i knew about my Environment variables, but there was nothing pointing to my qt directory (did not came up with the path or set command) thats why i was wondering what was pointing to my qt install dir.
your link however came up with something my eyes fall on.
If a DLL with the same module name is already loaded in memory, the system checks only for redirection and a manifest before resolving to the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
So if i understand it correctly because i ran my application from visual studio (with the QtDir set in the environment of project settings ) before i ran my installed application(located in program filed) it could be possible the dll's where still loaded in the memory?
However the strange thing is if i reboot my computer and the first thing i startup is my installed aplication, it still loads dll's it is not supposed to find. (the dll's should not be in my memory because i rebooted)
There must be something else pointing to my qt installation dir....
@jsulm i knew qt's modules needs to load other modules but my problem was is that it found those modules in directories where it should not seek for modules.
i know it should not work, but it works and i have no idea why.
i know it should not work, but it works and i have no idea why
It should work and it does. No need for conspiracy theories ;)
Some of Qt dlls have embedded a path to the location they were built in. For an example open Qt5Core.dll in a text editor (yes, you read that right, a dll in a text editor) and look for
qt_prfxpath. You will see it's a variable set to the location where Qt was built in. It is also patched in as part of the installation process if you use Qt maintenance tool, to point to the installation directory.
The prefix location is one of the locations used to look for plugins so no matter where your app is placed it will look in the directory that embedded path points to. That's why it stops loading these plugins if you rename Qt's installation directory.
Part of a proper deployment is patching these dlls not to include any developer machine specific paths. That's one of the things windeployqt tool does and that's why you should prefer it instead of manual copying of the libraries. It patches this path to be
., which makes the deployed app look for plugins only in its own directory.
@Chris-Kawa Your answer takes the magic away, its all clear to me now. I did not even knew about the existence of the windeployqt tool.