I've managed to deploy a test app from Monterey which works on Catalina and Monterey and given up on building on Catalina after spending a few days trying to fix the result of macdeployqt using otool and install_name_tool.

It seems that the CMake qt_generate_deploy_app_script method doesn't work when run from Monterey either. Running the macdeployqt utility almost works out of the box, it just leaves the plugins' RPATH pointing to a nonexistent 'lib' folder where it expects Qt frameworks to be. Rather than fix the RPATH's in each of those plugin libs, adding a 'lib' symlink pointing to the Frameworks folder seems to do the trick.

In case it's useful to anyone, I've made a template repository on GitHub with this solution. The template allows you to deploy apps with LGPL Qt on Mac and Windows and use VSCode as an IDE rather than QtCreator:

https://github.com/yergin/qt-cmake-vscode

The relevant helper function is qt_mac_toQImage. Then QPixmap::fromImage can be used to get a QPixmap (example).

Qt6 is a whole new library. There's no way I'm going to try to build a Qt5 app with it. There's a 0% chance it would build. So I went through the trouble of figuring out how to apply those patches.

The link above is to a confusing web tool, but I eventually figured out that you can download the patches. Both of them are identical, so only one is needed. But the patch can't be applied to Qt5 automatically, so you'll have to manually edit the file.

If you downloaded the "qt-everywhere-src-5.15.2" archive, the file to patch is:

qtbase/src/plugins/platforms/cocoa/qiosurfacegraphicsbuffer.h

Somewhere before the line that says QT_BEGIN_NAMESPACE, insert this line:

#include <CoreGraphics/CGColorSpace.h>

Then configure without qtwebengine:

./configure -opensource -confirm-license -skip qtwebengine && make -j 8

Did you ever get an answer to this? I want to use many features of Qt but need to support Metal and it doesn't seem like there is an easy way with Qt widgets.

Hi and welcome to devnet,

Based on this Apple doc, one possible path could be to create a NSImage from the symbol and then a QImage/QPixmap from it.

Windows is running in a Virtual Machine (KVM) with Linux as its host, and the macOS is a Mac Mini Classic at MacInCloud.

If you removed the dynamic one, how does it still find it ?

You can modify the .pro file and pass the complete path to the static library

@Romain-C it is really odd - however I didn't do much work on High Sierra (it is very outdated). On Catalina and BigSur SSL support works out-of-the-box though.
Are you able to examine server side logs by any chance? This could help you to check if any connection is being made...

With regards to errors you should examine if QNetworkManager::SslErrors() signal is being emitted (simply connect to it) (I assume anonymousRequests is of type QNAM)

@Christian-Ehrlicher Good habit. I need to work on developing one.

You can also ask a Qbs question on a Discord server: https://discord.gg/ZXT6YKq (right now all Qbs developers and users live there). ;)

Thanks for the code !

You can use the Q_OS_XXX macros to ifdef your code.

@Sprezzatura
I think this looks better :)

Your code as it stands presumably leaks QNetworkRequest *request = new QNetworkRequest(url); and QNetworkAccessManager *nam = new QNetworkAccessManager;. You could put these on the stack (no pointers, no new). And I think you're supposed to deleteLater() the QNetworkReply *reply = nam->post(*request, content);.

You can get away without, but one day when you want examine your code for memory leaks with e.g. valgrind it will be better.

If you want a full static build, you'll have to build it yourself.

Please report this as a bug in JIRA, with a minimal test case, so that we can check whether this is a 5.15 regression, a Big Sur issue, or something also present in Catalina.

Well, the one coming from the QScreen doesn't seem to be correct either. I've got the QScreen from QApplication::primaryScreen()
and see following:

QScreen devicePixelRatio: 1 QScreen logicalDotsPerInch: 72 QScreen logicalDotsPerInchX: 72 QScreen logicalDotsPerInchY: 72 QScreen physicalDotsPerInch: 113.5 QScreen physicalDotsPerInchX: 113.5 QScreen physicalDotsPerInchY: 113.5

According to my user the DPI he should have 227 DPI:
"13-inch MacBook Pro models introduced in late 2012 or later. Native resolution: 2560 x 1600 at 227 pixels per inch. Support for millions of colors."

@fsfarimani no I have not checked each and every package. Also, not every package starting with qt has something to do with that framework. For example qtfaststart is a video related package.

If you want more information about the packages provided by brew, you should contact their maintainers. The Qt Project does not handle them.