[MacPorts] #70655: Qt6-qtbase, missing #include and an issue for (some) older systems

MacPorts noreply at macports.org
Thu Aug 29 12:07:22 UTC 2024


#70655: Qt6-qtbase, missing #include and an issue for (some) older systems
---------------------+------------------------
 Reporter:  Gandoon  |      Owner:  (none)
     Type:  defect   |     Status:  new
 Priority:  Normal   |  Milestone:
Component:  ports    |    Version:  2.10.1
 Keywords:           |       Port:  qt6-qtbase
---------------------+------------------------
 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/70655>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list