Installation and Deployment

I know this is an old post, but I figured I'd add this information as I ran into it. I don't think it is related to autogen or timestamps, I believe it is related to precompiled header files in general, because some of the failures I ran into had nothing to do with autogen, even thought some of them did: /Fdqtbase\src\openglwidgets\CMakeFiles\OpenGLWidgets.dir\ /FS -c qtbase\src\openglwidgets\CMakeFiles\OpenGLWidgets.dir\cmake_pch.cxx Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30153 for x64 Copyright (C) Microsoft Corporation. All rights reserved. ninja: build stopped: subcommand failed. 11:55:53 [836/4092] Building CXX object qtlanguageserver\src\jsonrpc\CMakeFiles\JsonRpcPrivate.dir\cmake_pch.cxx.obj 11:55:53 [837/4092] Building CXX object qtgrpc\src\protobuf\CMakeFiles\Protobuf.dir\cmake_pch.cxx.obj 11:55:53 [838/4092] Building CXX object qtserialport\src\serialport\CMakeFiles\SerialPort.dir\cmake_pch.cxx.obj 11:55:53 [839/4092] Building CXX object qtconnectivity\src\nfc\CMakeFiles\Nfc.dir\cmake_pch.cxx.obj 11:55:53 ninja: build stopped: subcommand failed. I was able to work-around it by disabling precompiled headers files by adding -DCMAKE_DISABLE_PRECOMPILE_HEADERS=ON to the CMake generation step. I was using the CMake with Visual Studio 2019 ( 3.20.21032501-MSVC_2) on Qt 6.7.3.

@Axel-Spoerl said in Qt VSTools versus CMake build: Is the cmake-gui any good? Just like git, I always found the command line easier to use.... So far, I have never really learned CMake in depth. I have run into problems with CMake on the command line when reconfiguring with different options (because you forgot one). The cmake-gui (and also ccmake on the command line) seem to do the correct thing in the background. Especially on Windows, the default of the cmake-gui is to generate a VS project (there is even a button to directly open the project from the cmake-gui). For someone without any knowledge of CMake this is a much better starting point (especially for 3rd-party libraries) than using the command line. One advantage of cmake-gui and ccmake is that you see all the different options that you can change. By default you only see the options of the project's CMakeList.txt, but you can toggle the advanced mode to see all CMake options as well.

Hi @studious-serpent, and welcome! Is there a way that I can force the tool to install the open source version? You'll need to log in with a different email address unfortunately.

@jsulm Thank you, that seems to have resolved my issue.

@Grit-Clef I mean to check the access rights for the DLLs where you get "could not be found" ("but those dlls are there...").

/usr/bin/c++ is the local compiler on Linux, not the cross-compiler, which on my system is x86_64-w64-mingw32-g++. That means, something in the configure step went wrong or the toolchain hasn't been installed correctly. See here for more info: https://doc.qt.io/qtvstools/qtvstools-how-to-cross-compile.html

So it won't copy the pdb files from my build dir to the deploy dir - OK understood - though I think it should!

Hi, How are you doing the notarization ?

@ZergedU said in Cannot run Qt Online Installer on Red Hat UBI 9, libxkbcommon-x11.so.0 missing: It looks like Red Hat UBI 9 strips down the AppStream repo from the RHEL version. Notably, the package "libxkbcommon-x11" is missing. Ah... that's a shame. I guess you'll need to resort to a 3rd-party repo then? (Or build it from source)

Hi @nazim, and welcome! The service provider was down for several hours: https://www.bleepingcomputer.com/news/technology/massive-heroku-outage-impacts-web-platforms-worldwide/ It is back online now, and you should be able to log in again.

Hi @montanaviking, open your downloaded file with a text editor. You'll see that curl has saved a HTML document, not an executable. Either use a web browser to download it, or ask curl to follow redirects.

Ah, ok, thx.

I tried this: if(NOT LINUX) set (deploy_tool_options_arg "-verbose=1") if(APPLE) set(deploy_tool_options_arg "${deploy_tool_options_arg} -hardened-runtime -timestamp -no-strip") set(deploy_tool_options_arg "${deploy_tool_options_arg} \"-executable=$<TARGET_BUNDLE_CONTENT_DIR:DeepSkyStacker>/MacOS/DeepSkyStackerCL\"") set(deploy_tool_options_arg "${deploy_tool_options_arg} \"-executable=$<TARGET_BUNDLE_CONTENT_DIR:DeepSkyStacker>/MacOS/uchmviewer\"") set(deploy_tool_options_arg "${deploy_tool_options_arg} \"-codesign=Developer ID Application: David Partridge (VH8AYT3C7Y)\"") and it seems to have worked ... Was that the best way to do it?

Same problem here with Qt 6.9.1: libunwind.dll and libc++.dll are missing. I believe it worked previously with Qt 6.8.0. And again, copying those files from C:\Qt\6.9.1\llvm-mingw_64\bin fixes it. Is it broken again or did I make a mistake?

@M4Z4 Hi, I'm not 100% sure I follow your launching process, but the error you're getting looks a lot like you are not setting the wayland display export in the same terminal as you run the QT application. Specifically, this part of the error message: Jan 13 11:55:32 sm2s-imx8mp cpx.sh[1628]: qt.core.plugin.factoryloader: Got keys from plugin meta data QList("wayland-egl") Jan 13 11:55:32 sm2s-imx8mp cpx.sh[1628]: qt.core.plugin.factoryloader: checking directory path "/opt/cpx/platforms" ... Jan 13 11:55:32 sm2s-imx8mp cpx.sh[1628]: qt.core.library: "/usr/lib/plugins/platforms/libqwayland-egl.so" loaded library Jan 13 11:55:32 sm2s-imx8mp cpx.sh[1628]: Failed to create wl_display (Connection refused) Jan 13 11:55:32 sm2s-imx8mp cpx.sh[1628]: EGL: Warning: No default display support on wayland Jan 13 11:55:32 sm2s-imx8mp cpx.sh[1628]: qt.qpa.wayland: EGL not available Jan 13 11:55:32 sm2s-imx8mp cpx.sh[1628]: qt.qpa.plugin: Could not load the Qt platform plugin "wayland-egl" in "" even though it was found. The connection to the display screen is refused. It looks like either 1) Your path to the wayland display is wrong (check ls -l ${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY} before running your QT application) or 2) the user running QT does not have permissions. You should be able to see test applications like weston-flower work as well

I reinstalled qt creator, and then i could compile (this also upgraded version from 6.9.0 to 6.9.1). Dont know what happend. I found one more clue. If i made a cmake project and targeted c++11 i could compile, all other combinations of cmake/qmake c++11/14/17 did not work.