Since Qt6 does not support Windows 7 anymore you have to choose an older qt installer from e.g. https://mirror.netcologne.de/qtproject/archive/online_installers/

Hi and welcome to devnet, Just keep using cmake. Here for Qt 5 Here for Qt 6

@kkoehne said in Qt6, qmake: Does 'QT += openglwidgets' imply 'QT += opengl'?: @Yuni said in Qt6, qmake: Does 'QT += openglwidgets' imply 'QT += opengl'?: If it works and it's unspecified behavior, then it may not work on other machines or for future Qt versions. Build and module dependencies usually don't change in a minor Qt version. For major Qt versions, things might get rearranged ... but then again there's no SC guarantee there in the first place :) I think it's good practice to explicitly declare all the dependencies that you explicitly rely upon though. But this is arguably a matter of taste. I would guess qopenglwidget.prf fetches qopengl.prf - you can take a look into them by your own. For QT variable, it's actually .prifiles: mkspecs/modules/qt_lib_qopenglwidgets.pri, mkspecs/modules/qt_lib_qopengl.pri ... I see, thank you so much! I'll declare them explicitly then. I've found the .pri files (without the leading 'q', that is, so e.g. qt_lib_opengl.pri) and openglwidgets indeed has a dependency on opengl, explaining why the project compiles without the explicit declaration.

@Christian-Ehrlicher thank you for your help :)

One thing about the static linking problem: it might be as simple as not having the libraries in the correct order.

Ok I understand. Thank you!

@UvQtcYZJuD7J5VW7 said in Dependencies missing after DLL compilation: Unfortunately, LabView is not very talkative. This is the only error message I get. I have already recreated the node. Ah, check the dependencies of the DLLs that you deployed. For example, libgcc_s_dw2-1.dll depends on other DLLs too. Otherwise I could programming the entire program in Qt and so I will not have the need to use a DLL. If you can do everything in 1 language, that makes life a lot easier.

@SGaist Thank you! This is very helpful to know.

I am on windows, but the company's policy and firewall restrictions make it very difficult to get and build the sources.

Looks like a build error, no ? Are you using a pre-built version of Qt ?

@SGaist Hello! I'm building a second app using QMySQL database, the first app (the one about this topic) works perfectly as expected, but the second tells me that the driver isn't loaded. QSqlDatabase: MYSQL driver not loaded QSqlDatabase: available drivers: QSQLITE QMYSQL QMYSQL3 QODBC QODBC3 QPSQL QPSQL7 I added mysql dll dir in PATH environment variable, but same problem stay the same.. Have you an idea please? EDIT: nevermind, I'm just stupid, I forgot the "Q" before "MYSQL" call in code line: QSqlDatabase db = QSqlDatabase::addDatabase("MYSQL"); Now it's: QSqlDatabase db = QSqlDatabase::addDatabase("QMYSQL"); and strangely, works better.. Again, thank you all for your help!

Adding to @JKSH, the qml option expects the path to the files in your project sources so it can parse them to pull all the required dependencies.

@Christian-Ehrlicher Thank you, I had a typo in the widget name in the ui file which I was able to find in the ui_mainwindow.h file.

AFAIK, it's the script that was used to bootstrap the port from qmake to cmake so it should do a pretty good job.

Hi, AFAIR, yes, but you are setting the dependency on the wrong level. In your top level folder, TestSuite should depend on lib like app does.

:( but thanks for the links.

If you did something like CONFIG = debug You, in fact, nuked the content of the variable and replaced it with debug. If you want to modify the content of such a variable, use either += or *=. The first to add a value and the second to add the value only if not already in the variable.

i am facing the same nightmare. it's 2weeks i'm stuck tryin' to obtain my static +openssl build and...no way. No issues compiling without openssl support. Any progress on that? Seems that nobody wants to help :(

@Bonnie .pro file is identify the path but the issue is, whenever I do rebuild at that time it is not call to linuxdeploy.sh. I want to know if any variable is call the to script on build.

@jsulm Uhmm now I'm starting to understand why @sierdzio told me this is not easy. I will do some google search on this subject, thanks for guidance.

Great ! Since you have it working now, please mark the thread as solved using the "Topic Tools" button so that other forum users may know a solution has been found :-) In case, there's an answer that provides the correct hint, you can also use the three button menu to mark it as the correct answer.

@Strohhut no problem, I was close to the end of my suggestions... So great it's not working ! Setting up a working android toolchain can be cumbersome 🙈 Son't forget to use the topic tools to set the topic to solved :)

Hi, I think you are looking for QMAKE_RPATHDIR.

@sergitab94 Sorry for this reply I know this is an old post, but I followed your steps one by one but still my build fails. Anyway opennssl static build with Qt really frustrated me... C:\Qt\Static5113OpenSSL\src\qt-everywhere-src-5.11.3\qtbase\bin\qmake.exe -install qinstall C:\Qt\Static5113OpenSSL\src\qt-everywhere-src-5.11.3\qtbase\mkspecs\winrt-x86-msvc2015 C:\Qt\Static5113OpenSSL\StaticOpenSSL64\mkspecs\winrt-x86-msvc2015 C:\Qt\Static5113OpenSSL\src\qt-everywhere-src-5.11.3\qtbase\bin\qmake.exe -install qinstall C:\Qt\Static5113OpenSSL\src\qt-everywhere-src-5.11.3\qtbase\mkspecs\winrt-x86-msvc2017 C:\Qt\Static5113OpenSSL\StaticOpenSSL64\mkspecs\winrt-x86-msvc2017 mingw32-make[1]: Target 'install' not remade because of errors. mingw32-make[1]: Leaving directory 'C:/Qt/Static5113OpenSSL/src/qt-everywhere-src-5.11.3/qtbase' mingw32-make: *** [Makefile:92: module-qtbase-install_subtargets] Error 2 mingw32-make: Target 'install' not remade because of errors.

@feistykittykat Don't know if I'm allowed to bump this bad boy up. Been struggling to use PVRVFrame or something similar to get openGL found on my machine, but I have no idea how to set it up for QT. Still not even sure if that's the source of my problem.

Since this is pretty old, the solution is to at the bottom of the .pri file to use the export function. For every QMAKE key word you need an export for it. In my above example I should append the following to the bottom: export(PRE_TARGETDEPS) export(QMAKE_EXTRA_TARGETS)

we would like to install different builds on the same machine and the place were would do that distinction would be on the .pro file, to then generate different values for the "version" value of "info.plist" file. We already have a portion of code that we can probably use to do something similar: codegen.commands = python "\"$${PATH}/Dir1/test.py\"" !isEmpty(VARNAME) { message($$VARNAME) codegen.commands += VarName=$$CONFNAME } I think we are getting there

@ruisebastiao well this is a rather hacky workaround to fix something Qt has broken within a LTS version. The thing is that libmali uses a unified lib which contains all symbols for EGL, OpenGL ES etc. so it would be wrong to apply a single .so name. It worked fine in 5.12.0 so it's probably time to come up with a solution for this "use absolute paths" nonsense has introduced. it works once you duplicate the unified lib & patch it. So Qt needs to deal with this kind of libs instead of forcing users to patch stuff. https://forum.qt.io/topic/104015/cross-compilation-generates-full-paths-in-libqt5gui-so-for-libglesv2-so-and-libgl-so-then-cannot-be-found-in-execution-time/3

@raven-worx Thanks!

@kenchan - Again, thanks. I've successfully used -Wno-missing-braces on the analyzer and editor, so it 'works' for at least some versions of the compiler. As for 'warn_on'/'warn_off', I had no trouble verifying their existence/function once I found them in the .pro file, but I had no prior warning to look for such a thing. I've been looking for QMAKE_CXXFLAGS, not weird macros that are defined in some middle ground between the .conf files and the .pro files. I don't understand how the .conf files work, much less how to successfully invoke half of the options documented there and elsewhere. On the other hand, I think that I've solved my main issue with the discovery of the hidden 'warn_off' in my library's .pro file. I have compile warnings again. More than I'd like, true, and I don't seem to be able to turn off specific warnings, but fixing the autogenerated code should get rid of the majority of the offending bits, so I can at least have some confidence in my builds again.

If I rename new folder in new_old, for example, the problem disappears. I also tried, Qt5.8, already installed in my system, same problem. Maybe tomorow, I will try Qt5.12 and let you know.

Oops! It worked in my last attempt, although it look a long time. So, my problem was Emscripten's version after all. Here is the version that worked: emscripten-1.37.1 Note: I've used emsdk to install Emscripten and I had to install a matching LLVM/CLang version: clang-e1.37.1-64bit

@smhrambo deleting the *.pro.user file often helps when you do such moves...