Specifying DLL location when multiple versions on a Windows PC
-
Hi,
I have an application built using Qt libraries from 2017. Everything works fine on customer PCs that don't have any other Qt libraries on them but on some PCs, where other applications have different/more recent versions of the DLLs, my application "crashes" in the call to 'init'.
I'm assuming that the application is finding the more recent versions of the Qt DLLs and there is some mismatch between them.
So, the question is, how do I force my application to find the DLLs that I built it with? The folder where the application exe is installed contains the DLLs and i've tried prefixing the user and system 'path' environmentals with '.' and it didn't seem to help. (although I was not able to reboot the PC in question so that might still work).
Is there a better way or is there a known DLL path environmental for Qt libraries?
K
-
Hi,
I have an application built using Qt libraries from 2017. Everything works fine on customer PCs that don't have any other Qt libraries on them but on some PCs, where other applications have different/more recent versions of the DLLs, my application "crashes" in the call to 'init'.
I'm assuming that the application is finding the more recent versions of the Qt DLLs and there is some mismatch between them.
So, the question is, how do I force my application to find the DLLs that I built it with? The folder where the application exe is installed contains the DLLs and i've tried prefixing the user and system 'path' environmentals with '.' and it didn't seem to help. (although I was not able to reboot the PC in question so that might still work).
Is there a better way or is there a known DLL path environmental for Qt libraries?
K
@kennyT1
So far as I recall, Windows picks up DLLs in the current directory/same directory as the executable first, before doingPATHetc. It does not matter whether you or do not have.anywhere inPATH. So if you have supplied all your desired DLL versions in the same directory as the executable that should be right. However, it only takes one required DLL not to be in that directory to be at the mercy ofPATH, which you can't control. Check for all your dependent DLLs (I believe https://github.com/lucasg/Dependencies is the modern checker.). This is the sort of thingwindeployqtis supposed to sort out for you. -
@kennyT1
So far as I recall, Windows picks up DLLs in the current directory/same directory as the executable first, before doingPATHetc. It does not matter whether you or do not have.anywhere inPATH. So if you have supplied all your desired DLL versions in the same directory as the executable that should be right. However, it only takes one required DLL not to be in that directory to be at the mercy ofPATH, which you can't control. Check for all your dependent DLLs (I believe https://github.com/lucasg/Dependencies is the modern checker.). This is the sort of thingwindeployqtis supposed to sort out for you.@JonB
tks. I've run CFF Explorer on the exe and there's a single DLL that needs the various Qt DLLs to be available and none of them are showing up as missing in an installation.i'll ask the customer that is having the issue to try it himself and see if anything shows up...
K
-
@JonB
tks. I've run CFF Explorer on the exe and there's a single DLL that needs the various Qt DLLs to be available and none of them are showing up as missing in an installation.i'll ask the customer that is having the issue to try it himself and see if anything shows up...
K
-
@kennyT1 Have you followed down dependents of dependents? Issue can arise because of other DLLs the Qt DLLs depend on, and finding unacceptable version.
-
If you don't see anything missing in Dependencies you can also run your app under debugger and look at the loaded modules list. It will tell you all the dlls and paths it loaded them from.
If it's not a missing dll in deployment then the search order is a bit more complicated. The app location is 7th on the list, so there are a couple ways to override the dlls you're shipping with. Usually apps shouldn't use any of those, but there are unfortunately a bunch of misbehaving apps (viruses included) that do. The most straightforward one would be the "Known DLLs" list, which is a registry key that some app could have written to.
-
Hi,
I have an application built using Qt libraries from 2017. Everything works fine on customer PCs that don't have any other Qt libraries on them but on some PCs, where other applications have different/more recent versions of the DLLs, my application "crashes" in the call to 'init'.
I'm assuming that the application is finding the more recent versions of the Qt DLLs and there is some mismatch between them.
So, the question is, how do I force my application to find the DLLs that I built it with? The folder where the application exe is installed contains the DLLs and i've tried prefixing the user and system 'path' environmentals with '.' and it didn't seem to help. (although I was not able to reboot the PC in question so that might still work).
Is there a better way or is there a known DLL path environmental for Qt libraries?
K
@kennyT1 said in Specifying DLL location when multiple versions on a Windows PC:
my application "crashes" in the call to 'init'.
What is
initdoing?What version of Qt? What was the source of the DLLs? In recent years, officially distributed Qt DLLs have a major version number embedded in the name. E.g.,
Qt5Core.dlland not a bareQtCore.DLL.Aside from the main Qt DLLs there are dynamically loaded plugins which may be missing or mismatched (these will not show in a static dependency check). Check that all the requisite plugins are present in folders alongside your executable. Do these come from the same build of Qt as the main libraries?
You can use an environment variable to help debug plugin failures.Is there a
qt.conffile alongside your application? This can change where Qt looks for various things.
