Qt6-qtbase, missing #include and an issue for (some) older systems

[Gandoon (Erik Hedlund)]

Trying to upgrade to qt6-qtbase @6.7.2_0 on a MacOS 10.15.7 I ran into what first seemed to be an obscure build error. Tracing the problem back to corelib/thread/qfutex_mac.p.h. What happens is that there is an undeclared identifier:

. . .
:info:build In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt6/qt6-qtbase/work/qtbase-e
verywhere-src-6.7.2/src/corelib/thread/qmutex.cpp:11:
:info:build In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt6/qt6-qtbase/work/qtbase-e
verywhere-src-6.7.2/src/corelib/thread/qfutex_p.h:37:
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt6/qt6-qtbase/work/qtbase-everywhere-src-6.7.2/src/corelib/thread/qfutex_mac_p.h:120:28: error: use of undeclared identifier 'ETIMEDOUT'
:info:build     return r == 0 || r != -ETIMEDOUT;
:info:build                            ^
:info:build 1 error generated.
. . .

After a little digging I realised that the identifier comes from errno.h which is never included unlike in the equivalent corelib/thread/qfutex_linux.p.h and corelib/thread/qfutex_freebsd.p.h. In the previous MacPorts supplied version, qt6-qtbase @6.4.3_6 the corelib/thread/qfutex.p.h was not versioned between various platforms and did include errno.h.

The solution to this issue was to add #include <errno.h> in corelib/thread/qfutex_mac.p.h. I am a little bit unsure as to why the value is negated, -ETIMEDOUT, as it is not done for neither Linux nor FreeBSD, and it was never done in the earlier versions either. I left it as is, but we shall see if it gives me any problems. This is really a problem that should be pushed upstream, as Qt still seems to lack that include for Macs. Meanwhile, MacPorts could potentially add the include in a patch to avoid build errors.

On top of this, there seem to be an issue for at least some older systems. In plugins/platforms/cocoa/qcocoaapplicationdelegate.mm there is a snippet that generates an error on my 10.15.7 system:

...
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt6/qt6-qtbase/work/qtbase-everywhere-src-6.7.2/src/plugins/platforms/cocoa/qcocoaapplicationdelegate.mm:357:20: error: cannot initialize return object of type 'BOOL' (aka 'signed char') with an rvalue of type 'id'
:info:build             return [reflectionDelegate applicationSupportsSecureRestorableState:application];
:info:build                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:info:build 1 warning and 1 error generated.
...

It is intended for newer systems than mine, so I could work around it by just getting rid of that bit. Nevertheless, if anyone else have the same issue, you could try this:

...
- (BOOL)applicationSupportsSecureRestorableState:(NSApplication *)application {
  // This bit is causing trouble for me, and is not relevant on my system.
  // Commenting out the following if statement to not even try it.

  // if (@available(macOS 12, *)) {
  //    if ([reflectionDelegate respondsToSelector:_cmd])
  //        return [reflectionDelegate
  //        applicationSupportsSecureRestorableState:application];
  //}

  // We don't support or implement state restorations via the AppKit
  // state restoration APIs, but if we did, we would/should support
  // secure state restoration. This is the default for apps linked
  // against the macOS 14 SDK, but as we target versions below that
  // as well we need to return YES here explicitly to silence a runtime
  // warning.
  return YES;
}
...

It is always much harder to find something that is not present but should be if you don't know what to look for.

[Gandoon (Erik Hedlund)]

Build log qt6-qtbase @6.7.2_0

[Gandoon (Erik Hedlund)]

Workaround for (some) systems older than 12

[ryandesign (Ryan Carsten Schmidt)]

Replying to Gandoon:

This is really a problem that should be pushed upstream

Right, assuming these problems are not in patchfiles that we have added to the port, please report these problems to the developers of Qt so that it can be fixed at the source.

[reneeotten (Renee Otten)]

You should not have been prompted to update Qt6 on macOS 10.15 as it’s not supported there - so no point sending this upstream…You instead should have stayed on 6.4.2 - at least that is how it was intended. So there is something not correct in the Qt6-related PortGroups and/or I made a mistake when doing the update; I’ll try to correct that.

It appears to be tricky enough to get everything to build on upstream supported systems (likely related to SDK versions and such) and I don’t have the time/interest/capabilities to do the work to try and get it to work folr older OSes. Marcus has been doing a great job at that, but hasn’t been around much lately. So not sure of how much help I can be here… I am afraid that once you possibly fix this thing here it will break in other places and the patch-work will keep continuing.

[Gandoon (Erik Hedlund)]

Replying to ryandesign:

Replying to Gandoon:

This is really a problem that should be pushed upstream

Right, assuming these problems are not in patchfiles that we have added to the port, please report these problems to the developers of Qt so that it can be fixed at the source.

No, they are not. MacPorts did not introduce these issues. They are present in the Qt GitHub repository.

[Gandoon (Erik Hedlund)]

Replying to reneeotten:

You should not have been prompted to update Qt6 on macOS 10.15 as it’s not supported there - so no point sending this upstream…You instead should have stayed on 6.4.2 - at least that is how it was intended. So there is something not correct in the Qt6-related PortGroups and/or I made a mistake when doing the update; I’ll try to correct that.

It appears to be tricky enough to get everything to build on upstream supported systems (likely related to SDK versions and such) and I don’t have the time/interest/capabilities to do the work to try and get it to work folr older OSes. Marcus has been doing a great job at that, but hasn’t been around much lately. So not sure of how much help I can be here… I am afraid that once you possibly fix this thing here it will break in other places and the patch-work will keep continuing.

So far the only other package I noticed any issues with for now is qt6-qtdeclarative. I may return with suggestions for older system users if it can be easily patched, but after reading this comment, I may not put too much effort into it and just revert to @6.4.2. We shall see if I have the energy. So far the only issues I saw seems to have been calls to functions not available on older systems and Qt had already covered some of the unsupported older systems with fallbacks. I have come across these available() functions before, e.g. I believe it is in iTerm2.

I do realise that some manual tweaking is sometimes needed if one wishes to remain on an older system. It ends up being almost like a hobby to keep the system running as well as possible ;)

[reneeotten (Renee Otten)]

@Gandoon just to be clear: if you're willing/able to patch Qt6 in such a way that it will function on macOS 10.15 that would be certainly much appreciated. Patches and improvements to that end will certainly be reviewed/accepted in MacPorts; there are many packages that are able to be build with MacPorts for older OS versions than officially supported by upstream. In fact, as I said earlier Marcus has been doing a lot of that for the Qt5/Qt6 ports. It's just that I lack the time/interest/knowledge to do so, and my ability to test things is limited as I don't have any older OS installed/available.

In short, I didn't intend at all to discourage you to try to work on this!

[Gandoon (Erik Hedlund)]

I have an update to the adjacent qt6-qtdeclarative issue I hinted at previously exists for MacOS 10.15 (and probably older).

Qt 6.7 development tools are unfortunately ​not officially supported on MacOS 10.15 and earlier. However, as far as I can tell, deployment on older systems still is. It is possible to patch the source to build on 10.15 and to build applications using it (qBittorrent being a test case for me). Due to not being supported, it is unclear if everything will work as intended, but for me it worked. The latest version of qBittorrent seems to depend on Qt 6.7, so I had an incentive to try to find a patch.

Would there be any interest in me opening a separate ticket for that port and post the patch suggestion there? It requires a manual adjustment to make sure a certain destructor is correctly declared and used. We shall see if I have any memory left when I am done here ;)