I am in the process of learning how to create applications using Qt. I created a small app that is running fine on any machine that has Qt installed. I want to deploy using dynamically linked Qt libraries to Windows. I followed the instructions found here and with some help of other Stackoverflow articles I was able to get the application running without error, but now nothing shows up. There should be a small UI with buttons and such, but it isn't being displayed despite the fact that Windows Task manager reveals that the application is running.
My first thought was that I was missing some dll files, but even if I copy every dll found in C:\Qt\5.5\msvc2013_64\bin, the entire C:\Qt\5.5\msvc2013_64\plugins directory, msvcp120.dll, msvcr120.dll and the plaforms\qwindows.dll to the application directory I still cannot get it to display the UI.
The same application will run on any Win x64 machine with Qt installed. I just don't find asking users to download a 700mb set of tools to run a 9kb application a very robust solution.
What step am I missing for Qt deployment to Windows?
For specifics I have made this an open source project. You can see the release version of the application built in the bin/Win_x64 directory with all .dll files that I believe are necessary to run the application. If you copy that folder onto a Win x64 machine that doesn't have Qt installed then you should be able to reproduce my error.
Edit1:
I was asked to provide the list of files in my build/Release directory:
ArkCharacterSelector.exe
ArkCharacterSelector.res
CharacterManager.obj
Logger.obj
main.obj
moc_CharacterManager.cpp
moc_CharacterManager.obj
qrc_qml.cpp
qrc_qml.obj
Here are the files that are missing from master/bin/Win_x64:
bin/Win_x64
├── QtQuick (both dirs are from qt_base_dir/qml/QtQuick)
│ ├── Controls
│ └── Window.2
├── QtQuick.2 (both files are from qt_base_dir/qml/QtQuick.2)
│ ├── qmldir
│ └── qtquick2plugin.dll
│
│ (Those are only needed for QtWebKit builds)
├── icudt53.dll
├── icuin53.dll
└── icuuc53.dll
And these files can be removed:
bin/Win_x64
└── platform
├── qwindowsd.dll (debug dll)
└── qwindowsd.pdb (only needed for debugging the debug dll)
Happy deployment!
Related
I'am using flutter for desktop.
The release folder (flutter build windows) contains the executable, the dlls and a data folder with all my assets including icons. Is there a way to compile these assets into the executable to prevent them from being easily copied or stolen.
The assets section inside pubspec.yaml looks like this:
I have the following issue. I downloaded this sample project.
I develop primarily on Windows 10 however for the iOS part I purchased a VM from macinthecloud.com
I have a real iPhone device however since we use VM I cannot connect it, or it is too complicated/expensive. My goal was to create ipa/zip file which I can later use for UI tests through Appium. I purchased Apple Developer Account and was able to create an ipa file.
It is installed on the simulator however if you try to run it, it immediately crashes. I read everything I could find, some people suggest that probably the build architecture is wrong. The only available option from this MacOS VM is ARM64.
The following error was displayed from the simulator debug log:
Nov 10 10:13:06 DXU684 com.apple.CoreSimulator.SimDevice.AEDE77F9-AFD7-4788-9F69-9FB6FA9CDF54[63635] (com.apple.videosubscriptionsd[64306]): Service exited with abnormal code: 1
Nov 10 10:13:08 DXU684 com.apple.CoreSimulator.SimDevice.AEDE77F9-AFD7-4788-9F69-9FB6FA9CDF54[63635] (UIKitApplication:com.xamarin.standardcontrols[0x2a65][63661][64308]): Program specified by service does not contain any valid architectures for this system.
Can you please suggest how I can handle the problem? I need to run the Xamarin app on the Simulator installed through Appium (which is going well, guess is the primary problem of the build settings)
Program specified by service does not contain any valid architectures for this system.
In a IPA build, there is no x86_64 option as there are no x86-based iOS devices, only ARM-based.
What you could do is build for simulator/x86_64 and drag/drop the resulting .app to the simulator (or install via xcrun simctl install..., which is what everyone uses (Appium, Xamarin, ...) for controlling the simulator).
The .app is generated in the bin/iPhoneSimulator directory, example below:
├── bin
│ └── iPhoneSimulator
│ └── Debug
│ ├── device-builds
│ │ ├── iphone11.4-12.0
│ │ │ ├── ios_XXXX.app
│ │ └── iphone11.4-12.1
│ │ ├── ios_XXXX.app
Note: Building via Xcode 10.1 / iOS 12.1 / Xamarin.iOS 12.2.?.? will produce an .app that produces an .plist error when installed via drag/drop, but not when installed via simctl. This does not occur on earlier Xamarin.iOS 12.x versions and "assume" it is a Xamarin bug as the plist is slightly malformed when compared to an Xcode build (simctl does not seem to care, but the simulator GUI does...)
Hi I am trying to compile a program for windows using these instructions on github. I have installed the required dependencies (VS2017, cmake, cuda 8, amd app sdk 3.0).
I have placed the required xmr-stak-dep.zip in my C:/ folder, and the command tree. does line up with what is shown. The files are all accessible.
C:\xmr-stak-dep>tree .
Folder PATH listing for volume Windows
Volume serial number is XX02-XXXX
C:\XMR-STAK-DEP
├───hwloc
│ ├───include
│ │ ├───hwloc
│ │ │ └───autogen
│ │ └───private
│ │ └───autogen
│ └───lib
├───libmicrohttpd
│ ├───include
│ └───lib
└───openssl
├───bin
├───include
│ └───openssl
└───lib
The problem is when the program is finally built by running the commands below; when the program is executed I recieve the error libeay32.dll & ssleay32.dll cannot be found. The command below does show that it did set cmake to that path containing those ddl files.
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsMSBuildCmd.bat"
set CMAKE_PREFIX_PATH=C:\xmr-stak-dep\hwloc;C:\xmr-stak-dep\libmicrohttpd;C:\xmr-stak-dep\openssl
mkdir build
cd build
I have found this post that does show possibly how to fix this, but I am unsure how I would use the command with my configuration being this is my first time ever compiling a windows program.
As a note, I used the dev branch from here for the source.
There is nothing wrong with your compilation. It's just that your program depends on those DLLs. Windows only looks in certain places when trying to find the DLLs that a program depends on.
This article describes how windows looks for DLLs: https://learn.microsoft.com/en-us/cpp/build/search-path-used-by-windows-to-locate-a-dll
The easiest options are to copy the openssl .dlls into the directory alongside your .exe, or to add the directory containing them to your path. The latter can be done temporarily via set PATH=C:\XMR-STAK-DEP\openssl\lib;%PATH% (presuming the DLLs are under openssl\lib else substitiute openssl\bin)
im trying to build an audio unit synth and I've got it to compile but and it works so far but I want to debug it properly by setting my daw as a debug exexuble. The problem is that the daw only loads plugings that are in the component folder and xcode says it doesn't have permission to build there.
You should set up a build step to copy the plugin from the built products directory to your components folder. Aside from the fact that the internal built products directory is internal, the AU tools on Mac will only look for plugins in the system and user components directories, unlike VST which can be an arbitrary path.
The script would look something like this:
cp -r "$BUILT_PRODUCTS_DIR/$PRODUCT_NAME.component" "$HOME/Library/Audio/Plug-Ins/Components"
I would like to have a tools repository structured like so:
tools
|-- gnu
| `-- gcc
| |-- 4.6.0
| `-- 4.6.2
|-- microsoft
| `-- stylecop
| `-- 4.6.2.0
...
So that every developer across the company has the same tools during the build process.
Is it possible to create a 'build jail' in this way?
I don't know how to get the GNU tool-chain into a repository this way?
Does anyone have any experience with this? I've heard of chroot build jails.
I have a requirement to build on Windows and Linux.
The Debian (and thereby Ubuntu) people have developed the excellent pbuilder package for such issues. It originally creates a tarball with a minimal Debian environment that is unpacked into a chroot, but can easily be adapted for your requirements.