Installation and Deployment

I found this (after a bit of digging):

https://forum.qt.io/topic/159779/deployment-on-linux

It answers most of my questions for now. I'll mark this as solved and come back later it I need to.

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.

Remaining is: how can the installer process silently crash and pull the entire linux "system" (wsl) into the abyss?

@Pl45m4 said in Downloading qt-enterprise-linux-x64-6.5.6.run:

Is usdp an official Qt Host?!

I don't know nor do I care :)

@turmoiloil said in Detected locale "C" with character encoding "ANSI_X3.4-1968":

why am i still getting this error

Looks like Qt does not support C.UTF-8.
How did you install Qt?

@DelayedNeutronss Try another mirror.
See here how to do this: https://wiki.qt.io/Online_Installer_4.x ("Selecting a mirror for opensource")

You're welcome !

Since you have it working now, please mark the thread as solved using the "Topic Tools" button or the three dotted menu beside the answer you deem correct so that other forum users may know a solution has been found :-)

Compiler: GCC 11.04

@DQUY05 said in Run the application with Debug error with static library:

Is there something wrong with the static library add operation

You're not linking the library which contains tesseract::TessBaseAPI.
Check the build log for warnings about incompatible library.

If you still have the old folder where you compiled, it will be a lot faster because make will just skip the things that have already been built. On the other hand, ther might also be some defines which are added, so I'm not entirely sure if this triggers a full rebuild (or should retrigger, but doesn't). You'll only be on the safe side when you do a fresh compile.

I found the issue, my brand-new Fedora 41 install didn´t had Mesa and Vulkan developer libraries installed, and Qt generated that totally not-useful error message...

Hi, using a Qt5 platform plugin for a Qt6 app does not work as you noticed.
Also mixing Qt 6.8 and 6.4 is a bad idea. If you're out of disk space for installing Qt 6.8, using the default Qt 6.4.2 that comes with Debian 12 is probably your best bet.

@jsulm Oke thanks for all the help

You should ask the Qt Company - this is a user driven forum which has nothing to do with any commercial things.

@Umbrecht said in Using static Qt for project with MinGW64:

C:\msys64

Don't mix MinGW and MSys.

It looks a lot like you are on macOS. By default menu entries will be rearranged to their "proper" position on macOS if they match a specific string. "Einfügen" is certainly such a string. And it is a single menu action and not a submenu. I know there is a switch in Qt to turn it off, but I couldn't find it right away.

From what I have found out the fancy compositor can either be run

with the eglfs backend not requiring another running wayland display server using another running wayland display server and attaching to it to run on top of it.

Note: check what wayland servers are already running and then must create a new one when launching the custom Qt compositor. On the stm32mp1 for example a wayland server 'wayland-0' was started once but is now now working correctly anymore so do not attach to it. We also have a 'wayland-1' server running and a 'wayland-1.lock' in the /home/Weston folder. Therefore you should attach your custom compositor to wayland-1 but not name it wayland-1.

Either pass it on the command line when starting

./fancy-compositor --wayland-socket-name 'nested-compositor'

Or specify in the QML code

WaylandCompositor { id: waylandCompositor socketName: "wayland-nested"

And then for running it use the wayland-1 server

WAYLAND_DISPLAY=wayland-1