I’ve had some confusion on how to setup Qt environment variables in the past. These notes are to help clarify some things. These notes apply to Qt6 (v6.3) installed from Qt’s unified installer for Windows, Windows 11, and Visual Studio 2022, but may be applicable to other platform combinations as well.
For my typical Qt/cmake projects, the only “Qt-related” environment variable that was needed to successfully run cmake and buyild in VS2022 was CMAKE_PREFIX_PATH.
CMAKE_PREFIX_PATH=C:\Qt\6.3.0\msvc2019_64
Even though I am using VS2022, the msvc2019_64 specification seemed to work. In other words, I was able to open the solution file that was generated in VS2022 and build my test project without errors.
Once I built the project (an executable application with a GUI) and attempted to run the exe file output, I got a Windows error complaining that one of the Qt shared libraries could not be found. This was resolved by adding the location of the Qt DLLs to my path environment variable. I elected to do this by following a previous pattern I had followed using Qt. I first set QTDIR to point at the installation location for the version I was using. I was initially unsuccessful because the installation directory structure for the unified installer was different than the “build from source” installations for Qt I had used in the past. I’m not sure at this point if/how “QTDIR” is “officially” used in any way, but I also use this environment variable in scripts to locate DLLs for distribution, and other purposes.
QTDIR=C:\Qt\6.3.0\msvc2019_64
Getting back to the Windows DLL-not-found issue, I mentioned that I needed to get the DLL directory references in the system “Path” environment variable. Now that I had QTDIR set, I could use it as a base to add “%QTDIR%\bin” to my system Path environment variable. Once I did this, the exe file that I previously built would now run (showing the Qt based GUI) without the Windows DLL error.
As a reminder, when changing system variables, applications will likely need to be restarted in order for system variables to be set and available. System variable appear to be read only at application start for most applications – including cmd (Windows command prompts), mintty terminal windows, and Visual Studio. In Windows, I edit environment variables in the system properties environment variables configuration dialog.
As shown in the image above, I’ll usually add environment variables in the system variables section (not limited to a single user). After making changes, I will verify that changes take effect by opening a new cmd window and using the “set” command.
The reason for this additional verification step is to first ensure that I have not made any mistakes. Second, I had noticed in the past that sometime environment variables would not take effect until a user had logged out and then back in. I’m not sure if this ever effected variables set in this system window, but specific scripts I was using to set environment variables would have this issue, so I got in the habit of verifying environment variables this way (in a new cmd window).