I have been looking for the same thing, but unfortunately the Qt Company does not seem to offer a documentation on the subject just yet. I had to go through the Qt's source codes, but finally found a solution:

Assuming your host OS is Windows x86_64 and you want to compile Windows arm64 packages for your project.

Install both versions (arm64, x86_64) of Qt and MSVC (make sure you select arm64 packages when you are installing MSVC on Visual Studio Installer; not arm). Compile your project with the following commands (on cmd.exe):cd your_project_folder call "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsamd64_arm64.bat" C:\Qt\6.8.0\msvc2022_arm64\bin\qt-cmake.bat -S . -B build-arm64 -G Ninja -DQT_HOST_PATH=C:\Qt\6.8.0\msvc2022_64 -DCMAKE_BUILD_TYPE=Release cmake --build build-arm64 --parallel --config Release

Assuming you are using Ninja as the generator (but you can remove -G Ninja if you don't)

Deploy your project with windeployqt by passing --qtpaths option like below (on cmd.exe):C:\Qt\6.8.0\msvc2022_64\bin\windeployqt.exe --qtpaths "C:\Qt\6.8.0\msvc2022_arm64\bin\qtpaths.bat" ...

So we are using windeployqt.exe from the msvc2022_64 setup, but letting it use the msvc2022_arm64 setup while deploying the dependencies by passing the --qtpaths argument.

I have built my project with that but was not able to test it on an arm64 machine yet, so please let us know if it works.

Edit 1: Apparently this requires that your Qt installation do reside in C:\Qt path. If your Qt installation path is different than that, you may try to circumvent this problem by editing out the paths listed in ...msvc2022_arm64\bin\target_qt.conf file.

Edit 2: There seems to be a bug in the Qt 6.8.0 win64_msvc2022_arm64_cross_compiled setup (i.e., I realized it when I installed it via the aqtinstall tool on my CI machine; but there was no such bug when I installed the same Qt setup to my personal computer using official Qt installation tool a few days back.) Make sure the path to your x64 setup inside the C:\Qt\6.8.0\msvc2022_arm64\bin\qtpaths.bat file is correct (edit the bat file if it contains the wrong path due to the bug I just mentioned).

Hope it helps.

@JKSH Hey, thanks for the answer and sorry for the very late reply.

My path: C:\Qt\5.15.2\msvc2019\bin

The bitness of the windeploy.exe in that path is 32-bit.

It seems I misunderstood/forgot how the windeployqt is used, that I need to run it for each new release. The dll:s still are of different bitness from the application's .exe but I guess that's fine then...

It works now.

@esvo
[PROBLEM SOLVED]
Turns out its a problem that is independent of windeployqt or qtcharts. Will be logging my findings here in case anyone else comes across this specific-ish issue as well. (Or if anyone has other insights)

The qml files with the charts being loaded in use singletons. I registered these singletons in the c++ main. When I registered the singletons I have the code looking into the working directory for the singleton qml files using the QDir::currentPath() function.

The folder including all the singletons must be included in the same folder as the exe for the app to have access to these files. Dropping the folder with the singleton qml files into the same folder as the exe fixes the problem.

It's not related to Qt or windeployqt and it's not about how the exe is made. Windows has a defined search order when it loads linked dynamic libraries. Other dlls, like plugins or resources, that load later on demand can be relocated via qtconf file.

In short - that's just how Windows organizes dlls.
You can fiddle with the local startup environment e.g. make a batch script that adds the dependencies subdirectory to PATH or changes working dir and you'd start your app by running it, but it's quite unusual and ugly.

I'd say just get used to having bunch of dlls next to your exe, even if it's not to your taste. That's what Windows apps do.

Copy "libstdc++6.dll" from where the mingw bin files are located into your folder where the executable is located. This worked for me and it should work for yall :)

I think there is some problem with my vm machine, i tried on another one and it works.
Thanks for your help

@NicolasR said in windeployqt reduce size of app:

I would like to know, what args should I use to have the strict minimum ?

There are none - windeployqt does not modify the needed dlls, it just copies them.

@raven-worx
Thank you very much for your time, my issue is resolved :-)

It was indeed the debug build causing the issue, and I am using the correct qlmdir to avoid unnecessary imports.

Thank you again and have a nice day!

@Janani I would also check the Windows event log - maybe you find some hints there?

@J-Hilk Thanks for the reply. This adds a bit of complexity to my WIX installer since I don't want to list all 700+ files individually. Do you know if there is anyway to deploy these files in a folder other than where the executable is located? I would like to dump all of the QT dependencies in one folder (which can have subfolders) but I need to be able to "blow away" all of the Qt related dependencies by deleting one directory while being confident that I didn't delete anything but Qt dependencies.

@J-Hilk

I got it to work with ifw as well. However, the option --plugindir apparently does not work correctly. The plugins were stored in the folder of the exe.

However, also the installation using ifw was finally successful.

Thank you @hskoglund for this option, it worked!
This is the perfect solution for me, it's simple, and now I can use C++ variables for the install path of my DLL if needed.

Thanks again!

@JSher said in Building QT with "windeployqt": not connect to database (ODBC):

Its connecting to an OBDC entry in windows by the looks of it. I do not use ODBC much but the way I understand it is you have to make the entry on each machine....Thats why I use the standard mysql connector, then you do not. I could be off:)

Ok thank you very much!!! I evaluate the transition to the mysql connector

Hi and welcome to devnet,

What version of Windows are you using ?
Can you run your application from the same command prompt ?

Perhaps some dll files are missing.

That seems to suggest that it is fixed, but that isn't what I am experiencing. I don't know how I go about raising this as it is a closed thread.

@Vagabond please don't forget to mark your post as solved... thanks.

@AndersDK Not sure how to handle this (I don't do much on Windows). The correct runtime package from Microsoft must be installed on users machine. I do not know whether Microsoft allows to distribute this runtime. If not your installer could maybe download it from Microsoft if it is not installed and install then.