Installation and Deployment

Ahh, I see. Okay, thank you!

Yes I put a label and a button on the main widget with the qt form editor also I can start the widget project with the desktop MSVC qt kit but when I change to uwp MSVC kit I just get a blank window and lots of errors (see above). Also I did all updates one thing to say it is only a windows 10 vm but it should work anyway right?

In case anyone else hits the same problem, it is probably a path length issue. See https://lists.qt-project.org/pipermail/development/2016-November/027700.html for a similar problem. I had this problem and reduced the path length and now QtWebEngine has built fine.

It's not a problem of Qt Creator. The mkspec used for the RPI3 is still valid unless your sysroot comes from a Debian Stretch were they have changed the library name. You need to modify the mkspec under devices that matches the Rpi3

I was able to figure this out with more testing. I noticed that if I configured with the -no-opengl option I was able to compile/install without errors. This led me to looking into my .conf file to make sure I had my paths setup correctly. I used this configure input ./configure -release -opengl es2 -device linux-beagleboard-g++ -device-option CROSS_COMPILE=/opt/gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- -sysroot /mnt/Smartlog-rootfs -opensource -confirm-license -make libs -no-use-gold-linker -prefix /usr/local/qt5-SLL -extprefix /home/scorpion/Qt_Source/Qt_Installed/Qt_5.11.3_Beagleboard -skip qtserialbus -skip qtscxml -skip qtscript -skip qtcharts -skip qt3d -skip qtdatavis3d -skip qtcanvas3d -skip qtgamepad -skip qtvirtualkeyboard -skipqtwayland -skip qtwebengine -skip qtwebchannel -skip qtwebglplugin -qt-zlib -recheck-all and this .conf file MAKEFILE_GENERATOR = UNIX CONFIG += incremental QMAKE_INCREMENTAL_STYLE = sublib QMAKE_RPATHLINKDIR_POST += $$[QT_SYSROOT]/usr/lib/arm-linux-gnueabihf QMAKE_RPATHLINKDIR_POST += $$[QT_SYSROOT]/lib/arm-linux-gnueabihf include(../../common/linux.conf) include(../../common/gcc-base-unix.conf) include(../../common/g++-unix.conf) load(device_config) QT_QPA_DEFAULT_PLATFORM = eglfs # modifications to g++.conf QMAKE_CC = $${CROSS_COMPILE}gcc QMAKE_CXX = $${CROSS_COMPILE}g++ QMAKE_LINK = $${QMAKE_CXX} QMAKE_LINK_SHLIB = $${QMAKE_CXX} # modifications to linux.conf QMAKE_AR = $${CROSS_COMPILE}ar cqs QMAKE_OBJCOPY = $${CROSS_COMPILE}objcopy QMAKE_NM = $${CROSS_COMPILE}nm -P QMAKE_STRIP = $${CROSS_COMPILE}strip COMPILER_FLAGS = -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mthumb #modifications to gcc-base.conf QMAKE_CFLAGS += $${COMPILER_FLAGS} QMAKE_CXXFLAGS += $${COMPILER_FLAGS} QMAKE_CXXFLAGS_RELEASE += -O3 QMAKE_LIBS += -lrt -lpthread -ldl # Extra stuff (OpenGL, DirectFB, ...) QMAKE_INCDIR_EGL = $$[QT_SYSROOT]/usr/include/EGL QMAKE_LIBDIR_EGL = $$[QT_SYSROOT]/usr/lib/arm-linux-gnueabihf QMAKE_INCDIR_OPENGL_ES2 = $${QMAKE_INCDIR_EGL} QMAKE_LIBDIR_OPENGL_ES2 = $${QMAKE_LIBDIR_EGL} QMAKE_INCDIR_OPENVG = $${QMAKE_INCDIR_EGL} QMAKE_LIBDIR_OPENVG = $${QMAKE_LIBDIR_EGL} QMAKE_LIBS_EGL = -lEGL -lIMGegl -lsrv_um QMAKE_LIBS_OPENGL_ES2 = -lGLESv2 $${QMAKE_LIBS_EGL} QMAKE_LIBS_OPENVG = -lOpenVG $${QMAKE_LIBS_EGL} DISTRO_OPTS += hard-float # No need for any special EGL device integration. # Prioritize the default, compiled-in integration over any plugins. EGLFS_DEVICE_INTEGRATION = none include(../common/linux_arm_device_post.conf) load(qt_config) With these changes I was able to compile without errors and everything seems to be running as intended.

@aha_1980 Thanks - the second git clean step did the trick.

It seems this issue has come back (we're now 2019). It occurred to me several times. Restarting QtCreator works for me (terrible solution!)

Thanks for the help. I am going to mark this closed. Seems like loading MSVS 2019 does something to the MSVS2017 install. I was able to get it to run on a new machine without either Qt or MSVS already installed. I was able to get QtCreator running and compiling on the machine I had previously loaded MSVS 2019 installed but it was still doing flaky things.

@victor-wang I have chosen to go through desktop linux in a VirtualBox As @koahnig said , maybe using a VM for your development machine will save you time and headaches, since most of the toolchains for cross-compiling are available for Linux as first option

One thing I would do is to search through all the content of these folder to find out what defines the build type.

@hskoglund said in Windows deployment and missing DLL dependencies: One question: the list of dependent dlls for an .exe file only include the filenames, the source path windeployqt uses for the copying seems to be Qt's bin directory only. So, in order for your Qt5Pdf.dl to be successfully copied by windeployqt, did you first copy Qt5Pdf.dl into Qt's bin directory? Yep, both Qt5Pdf.dll and qca-qt5.dll are inside C:\Qt\5.12.3\msvc2017_64\bin (same folder as windeploy). They were automatically copied with their post-build installation

@FluxDice Hi and welcome to devnet forum Here is a link to the Qt documentation for cross compiling. https://doc.qt.io/qt-5/embedded-linux.html For raspberry specifically there is also https://www.raspberrypi.org/forums/viewtopic.php?t=204778

@r3d9u11 Well, topic was solved with previous version of toolchain (g++ v6)

Final Edit! Got it working thanks to you. The subdirectories got completely wiped for some reason, but after rebuilding the file with the correct Qt version for the project and using the proper version of Windeployqt, the application works! Thank you so much :) @jsulm By the looks of things, copying the Qt5Widgets.dll from the 5.11.2 version did not resolve the issue. Now it does not give out the same error, though. It says "No Qt platform plugin could be initialized" I could build the project again and re-do the deployment process. I'd just need to get another computer to test it on (which shouldn't be an issue). What do you think? Edit: It seems as if though for some reason the subdirectories got wiped? I'll investigate.

@J.Hilk Maybe, I have to try.