Unsolved Are Qt versions not backwards compatible?
-
@Poneva said in Are Qt versions not backwards compatible?:
They can run Qt creator and write software that runs under 5.12 on their system, but my 5.9 release build does not run there.
Where did you place your 5.9 executable? Where were the 5.12 DLLs located?
Why?
It is supposed to work, but there are many possible reasons why it might fail: Perhaps the DLLs were not in the correct locations. Perhaps the application was actually loading wrong DLLs. Perhaps there is a bug in Qt.
A good way to find out why is to inspect the DLL loading process. You can:
- Set the
QT_DEBUG_PLUGINS
environment variable (see https://doc.qt.io/qt-5/deployment-plugins.html#debugging-plugins ) and launch your application from the command line, OR - When the "could not find or load the Qt platform plugin" dialog is on-screen, run the ListDLLs utility (https://docs.microsoft.com/en-us/sysinternals/downloads/listdlls ) to see what has been loaded.
- Set the
-
I run our program from a USB stick after the client's folks installed 5.12 before my eyes and we rebooted the system.
@JKSH said in Are Qt versions not backwards compatible?:
@Poneva said in Are Qt versions not backwards compatible?:
They can run Qt creator and write software that runs under 5.12 on their system, but my 5.9 release build does not run there.
Where did you place your 5.9 executable? Where were the 5.12 DLLs located?
Why?
It is supposed to work, but there are many possible reasons why it might fail: Perhaps the DLLs were not in the correct locations. Perhaps the application was actually loading wrong DLLs. Perhaps there is a bug in Qt.
A good way to find out why is to inspect the DLL loading process. You can:
- Set the
QT_DEBUG_PLUGINS
environment variable (see https://doc.qt.io/qt-5/deployment-plugins.html#debugging-plugins ) and launch your application from the command line, OR - When the "could not find or load the Qt platform plugin" dialog is on-screen, run the ListDLLs utility (https://docs.microsoft.com/en-us/sysinternals/downloads/listdlls ) to see what has been loaded.
- Set the
-
@Poneva said in Are Qt versions not backwards compatible?:
I run our program from a USB stick after the client's folks installed 5.12 before my eyes and we rebooted the system.
Qt is not installed system-wide. When you double-click your EXE on your USB stick, the program tries to find the platform plugin DLL (
qwindows.dll
) in a subfolder on your USB stick; it can't see the version that your customer installed.The best way to run your Qt 5.9 program from a USB stick is to deploy your EXE and the Qt 5.9 DLLs to your USB stick: https://doc.qt.io/qt-5/windows-deployment.html
Note: Qt 5.9 reached end-of-life in May 2020. It is discouraged for use with new projects.
-
If this is the case, then the build must copy this DLL to the build folder. Why does it not?
@JKSH said in Are Qt versions not backwards compatible?:
@Poneva said in Are Qt versions not backwards compatible?:
I run our program from a USB stick after the client's folks installed 5.12 before my eyes and we rebooted the system.
Qt is not installed system-wide. When you double-click your EXE on your USB stick, the program tries to find the platform plugin DLL (
qwindows.dll
) in a subfolder on your USB stick; it can't see the version that your customer installed.The best way to run your Qt 5.9 program from a USB stick is to deploy your EXE and the Qt 5.9 DLLs to your USB stick: https://doc.qt.io/qt-5/windows-deployment.html
Note: Qt 5.9 reached end-of-life in May 2020. It is discouraged for use with new projects.
-
Because the compiler does not care about that nor the linker.
You can add instructions for that but it's not really practical. Usually your development environment is setup so that your dependencies can be found and once you are done you create the deployment through windeployqt and/or a package builder.
-
@Poneva said in Are Qt versions not backwards compatible?:
If this is the case, then the build must copy this DLL to the build folder.
No, copying the required DLLs is deployment. This is separate from building.
Please read the documentation about deployment, especially the section entitled "The Windows Deployment Tool": https://doc.qt.io/qt-5/windows-deployment.html
Why does it not?
Because programmers usually build many times during development but only deploy once at the end.
-
@JKSH said in Are Qt versions not backwards compatible?:
Qt is not installed system-wide.
If this was true, then my build would not work on other mathines with 5.9 installed. But it does. It just does not work on machines with 5.12.
-
@Poneva said in Are Qt versions not backwards compatible?:
@JKSH said in Are Qt versions not backwards compatible?:
Qt is not installed system-wide.
If this was true, then my build would not work on other mathines with 5.9 installed. But it does. It just does not work on machines with 5.12.
- How did you install Qt 5.9 on your machines?
- Did you add Qt 5.9 to your PATH?
- How did your customer install Qt 5.12?
- Did your customer add Qt 5.12 to their PATH?
- Did you build with static linking or dynamic linking?
- What other files (if any) are there in your USB stick with your built EXE?
-
I guess the sentiment here is that your users are always trying to screw you over by subverting the installations, messing up PATH and LIB_PATH, screwing around with DLLs etc. Truth is, we are not. We are petrified by the totality of open-source software's fragility and it being prone to issues arising from tampering with it, and we leave the installed software alone as only possible, partially from being aware that this will be the first thing that we will be accused off as soon as we begin to ask questions or making bug reports. Whatever the installer does, we do not change. We do not add, change, or remove environment variables. We are just not the types who are hell-bent on messing up other human beings, such we are. And those fellows at our customer are similarly minded souls: they run the installer and wave for us to proceed with the demo. We did not witness any tampering on their part either.
Your installer runs and dumps several gigabytes of stuff to whatever directory is its default. Then we launch Qt Creator and build something by pressing on the standard button in the bottom left corner. While it builds, we are breathless from fear of something going wrong and build failing. Once the build is over, we emit a huge sigh of relief, grab STAR dot STAR (since the forum swallows star characters) and nothing else from the release build directory, and dump it onto a USB stick.
Mind you, we do switch off shadow builds because they mess everything up more often than they do not. We are petrified by fear of shadow builds because they screw us over, 99% of the time. We hate them with passion and make sure they are never enabled. But I digress. So we grab STAR dot STAR (since the forum swallows star characters) from the release build and put it into a separate subdirectory on a USB stick. This includes the EXE and a bunch of Qt*.dll files that the build puts into the Release directory. Whatever the build process dumps there is everything that we copy, and everything that we copy is always that which is dumped into the Release directory by the build. The files that we copy over are only the files that appear after the build in the Release directory, by way of some magic. We only copy those files and none else. Whichever the build creates, is copied over.
It is none of your business what else is on the USB stick, for the obvious reasons of trade secrets and individual privacy. Suffice it to say that there is nothing else there that might be remotely capable of messing Qt up. We never touch Debug builds because they never work. An EXE launched from a Debug build directory always complains about something horribly missing, and crashes, so Release it is that we use.
Did I miss answering any of your questions?
@JKSH said in Are Qt versions not backwards compatible?:
@Poneva said in Are Qt versions not backwards compatible?:
@JKSH said in Are Qt versions not backwards compatible?:
Qt is not installed system-wide.
If this was true, then my build would not work on other mathines with 5.9 installed. But it does. It just does not work on machines with 5.12.
- How did you install Qt 5.9 on your machines?
- Did you add Qt 5.9 to your PATH?
- How did your customer install Qt 5.12?
- Did your customer add Qt 5.12 to their PATH?
- Did you build with static linking or dynamic linking?
- What other files (if any) are there in your USB stick with your built EXE?
-
@Poneva Instead of writing such aggressive and long posts you should read and learn what @SGaist suggested: how to deploy applications. https://doc.qt.io/qt-5/windows-deployment.html
-
@Poneva said in Are Qt versions not backwards compatible?:
I guess the sentiment here is that your users are always trying to screw you over by subverting the installations, messing up PATH and LIB_PATH, screwing around with DLLs etc.
It's nothing hostile like that. I'm trying to understand your dev environment, because what you described differs from what normally occurs with a default installation and the typical development process. So, I wanted to know things like:
- Did you use the Qt official installer, or did you obtain Qt from a 3rd party, or did you build Qt from source?
- Did you modify the environment or did you leave it as-is?
- Did you apply custom settings or did you use the defaults?
- Do you have an advanced build script/process that performs custom steps?
Your previous post answered #1 and #2 fully (official installer + unmodified environment). For #3, you described one set of custom settings (no shadow build -- although this does not affect the launching of your program). #4 can be deduced from your answers (see below).
Whatever the installer does, we do not change. We do not add, change, or remove environment variables.... And those fellows at our customer are similarly minded souls: they run the installer and wave for us to proceed with the demo. We did not witness any tampering on their part either.
This is good. This proves that your issues are not caused by non-standard installations or modified environments.
Then we launch Qt Creator and build something by pressing on the standard button in the bottom left corner.... Once the build is over, we emit a huge sigh of relief, grab STAR dot STAR... and nothing else from the release build directory, and dump it onto a USB stick.
All sounds good here.
This includes the EXE and a bunch of Qt*.dll files that the build puts into the Release directory. Whatever the build process dumps there is everything that we copy, and everything that we copy is always that which is dumped into the Release directory by the build. The files that we copy over are only the files that appear after the build in the Release directory, by way of some magic. We only copy those files and none else. Whichever the build creates, is copied over.
Now this is interesting. Because by default, Qt tools do not copy the Qt*.dll files into the EXE folder when building.
Don't believe me? Try this yourself: I opened Qt Creator and loaded Welcome > Examples > Analog Clock Window Example. I picked a kit and left it at the default settings (except that I disabled shadow builds to make it as similar to your setup as possible). I built the example by "pressing on the standard button in the bottom left corner", and this is the output:
The build process does not copy any DLLs whatsoever. And if I double-click analogclock.exe without deploying first, this is what I get (which is expected because the DLLs are missing):
Therefore, I suspect that your project contains custom build steps to perform deployment. The custom steps copy some Qt DLLs but some are missed.
It is none of your business what else is on the USB stick, for the obvious reasons of trade secrets and individual privacy.
The types of answers I was interested in are things like:
- "There's absolutely nothing else on the USB stick, only the EXE file by itself", or
- "There's the EXE file plus a custom qt.conf config file", or
- "There's the EXE file plus this set of Qt5*.dll files"
It sounds like yours is the last scenario (EXE file + some Qt5*.dll files)
Suffice it to say that there is nothing else there that might be remotely capable of messing Qt up.
Believe it or not, having an incomplete set of Qt DLLs on your USB stick is the reason for the weird behaviour that you originally posted about.
This is what happens: When you launch your EXE, it finds and loads Qt5Core.dll (among others) from the same folder. Qt5Core.dll then searches the same folder for plugin DLLs, especially
platforms\qwindows.dll
.In your case,
qwindows.dll
is missing from your USB stick, so Qt5Core.dll starts searching other folders (including the PATH). Qt 5.9.9's version of Qt5Core.dll is also like a salmon -- it remembers that it originally came from C:\Qt\5.9.9\msvc2015\ (or whatever compiler you used), so it searches that path too. Voila, it findsC:\Qt\5.9.9\msvc2015\plugins\platforms\qwindows.dll
on your test PCs and it is happy.So why didn't it work on your customer's PC? Because C:\Qt\5.9.9\msvc2015\ does not exist there.
Now, if you use the official deployment tool, your program will find qwindows.dll on your USB stick and wouldn't try to search for C:\Qt\5.9.9\msvc2015. This means it will work on your customer's PC which has Qt 5.12 installed. Heck, it will even work on a PC that does not have any Qt installed!
-
We do not even know that that 3d party installation packages exist. Building from source scares the living hell out of us, because it never works and requires costly, time-consuming R&D and lots of witchdoctoring, if stars align properly, which never happens. Something is always missing, or versions collide and mismatch. It is the official installer and a fearful prayer that works most of the times.
Like I pointed out incessantly, we do not touch the environment. We heard of terrible things that happen if we would, so we never do. Custom settings? God forbid, for the same reason. It's too fagile, so why ask for trouble? We do not. Advanced scripts? Same thing. We do not ask for trouble. I described everything in great detail: vanilla is our credo. Leave everything vanilla, do not touch anything if it works, or hell breaks loose.
@JKSH said in Are Qt versions not backwards compatible?:
@Poneva said in Are Qt versions not backwards compatible?:
I guess the sentiment here is that your users are always trying to screw you over by subverting the installations, messing up PATH and LIB_PATH, screwing around with DLLs etc.
It's nothing hostile like that. I'm trying to understand your dev environment, because what you described differs from what normally occurs with a default installation and the typical development process. So, I wanted to know things like:
- Did you use the Qt official installer, or did you obtain Qt from a 3rd party, or did you build Qt from source?
- Did you modify the environment or did you leave it as-is?
- Did you apply custom settings or did you use the defaults?
- Do you have an advanced build script/process that performs custom steps?
Your previous post answered #1 and #2 fully (official installer + unmodified environment). For #3, you described one set of custom settings (no shadow build -- although this does not affect the launching of your program). #4 can be deduced from your answers (see below).
Whatever the installer does, we do not change. We do not add, change, or remove environment variables.... And those fellows at our customer are similarly minded souls: they run the installer and wave for us to proceed with the demo. We did not witness any tampering on their part either.
This is good. This proves that your issues are not caused by non-standard installations or modified environments.
No, it does not. We do not modify. We do not use non-standard.
Then we launch Qt Creator and build something by pressing on the standard button in the bottom left corner.... Once the build is over, we emit a huge sigh of relief, grab STAR dot STAR... and nothing else from the release build directory, and dump it onto a USB stick.
All sounds good here.
This includes the EXE and a bunch of Qt*.dll files that the build puts into the Release directory. Whatever the build process dumps there is everything that we copy, and everything that we copy is always that which is dumped into the Release directory by the build. The files that we copy over are only the files that appear after the build in the Release directory, by way of some magic. We only copy those files and none else. Whichever the build creates, is copied over.
Now this is interesting. Because by default, Qt tools do not copy the Qt*.dll files into the EXE folder when building.
Don't believe me? Try this yourself: I opened Qt Creator and loaded Welcome > Examples > Analog Clock Window Example. I picked a kit and left it at the default settings (except that I disabled shadow builds to make it as similar to your setup as possible). I built the example by "pressing on the standard button in the bottom left corner", and this is the output:
The build process does not copy any DLLs whatsoever. And if I double-click analogclock.exe without deploying first, this is what I get (which is expected because the DLLs are missing):
Therefore, I suspect that your project contains custom build steps to perform deployment. The custom steps copy some Qt DLLs but some are missed.
It is none of your business what else is on the USB stick, for the obvious reasons of trade secrets and individual privacy.
The types of answers I was interested in are things like:
- "There's absolutely nothing else on the USB stick, only the EXE file by itself", or
- "There's the EXE file plus a custom qt.conf config file", or
- "There's the EXE file plus this set of Qt5*.dll files"
It sounds like yours is the last scenario (EXE file + some Qt5*.dll files)
Suffice it to say that there is nothing else there that might be remotely capable of messing Qt up.
Believe it or not, having an incomplete set of Qt DLLs on your USB stick is the reason for the weird behaviour that you originally posted about.
This is what happens: When you launch your EXE, it finds and loads Qt5Core.dll (among others) from the same folder. Qt5Core.dll then searches the same folder for plugin DLLs, especially
platforms\qwindows.dll
.In your case,
qwindows.dll
is missing from your USB stick, so Qt5Core.dll starts searching other folders (including the PATH). Qt 5.9.9's version of Qt5Core.dll is also like a salmon -- it remembers that it originally came from C:\Qt\5.9.9\msvc2015\ (or whatever compiler you used), so it searches that path too. Voila, it findsC:\Qt\5.9.9\msvc2015\plugins\platforms\qwindows.dll
on your test PCs and it is happy.So why didn't it work on your customer's PC? Because C:\Qt\5.9.9\msvc2015\ does not exist there.
Now, if you use the official deployment tool, your program will find qwindows.dll on your USB stick and wouldn't try to search for C:\Qt\5.9.9\msvc2015. This means it will work on your customer's PC which has Qt 5.12 installed. Heck, it will even work on a PC that does not have any Qt installed!
-
Core message
The core message from myself and everyone else still stands: If you want to avoid trouble, use windeployqt after you build your EXE before bringing it to another PC.
This lets you run programs built with Qt 5.9 on PCs that have Qt 5.12 installed. This even lets you run Qt programs on PCs that don't have Qt installed.
Other stuff
@Poneva said in Are Qt versions not backwards compatible?:
Like I pointed out incessantly, we do not touch the environment.
That is good. We agree with you: Vanilla keeps life simple for everyone.
But anyway, that first section of my post was only there to clarify why I asked my list of questions. Did you read the rest of my post? Did you try to understand how Qt loads plugins and how deployment works?
Advanced scripts? Same thing. We do not ask for trouble. I described everything in great detail: vanilla is our credo. Leave everything vanilla, do not touch anything if it works, or hell breaks loose.
Well, nothing in your descriptions explain why your build process copies the Qt5*.dll files into your EXE folder. As I showed you in my previous post, the vanilla Qt tools did not do it. If you still believe they do, build the Analog Clock Example and tell us the outcome.