qmake/nmake fails on MacOSX26.4 with Qt 6.11 with error implicitly declaring library function '__yield'

NW135

Hi
I'm trying to build a project on MacOS Tahoe 26.4 with Qt 6.11 and get the following error:

/Users/gb/Qt/6.11.0/macos/lib/QtCore.framework/Headers/qyieldcpu.h:37:5: error: 
      implicitly declaring library function '__yield' with type 'void ()'
      [-Werror,-Wimplicit-function-declaration]
   37 |     __yield();              // Generic
      |     ^
/Users/gb/Qt/6.11.0/macos/lib/QtCore.framework/Headers/qyieldcpu.h:37:5: note: 
      include the header <arm_acle.h> or explicitly provide a declaration for
      '__yield'

The sources of the application I am building come from a project that I do not own, therefore I am bound to use the components as they are with qmake/nmake. I was able to build the application with exactly the same source successfully with MacOSX26.2 and Qt 6.10.2 a few days ago.
Apple published an update to MacOSX26.4 very recently - looking at other posts about this topic, I updated MacOS, XCode, XCode command line tools, reinstalled the entire Qt, erased all my source repository and replaced with a fresh one from the author (= the version which built successfully before).

[ Edit ]

More precisely:

1. Just after Mac updated to 26.4, I first got the error "no such sysroot" for which you find information on this (older) post.

2. I tried changing QMAKE_MAC_SDK (in the file common.pri of the project) and delete the .qmake.stash files (under main and lib folders), after which I got the current issue even before reinstalling QT - so the issue already appeared with QT 6.10.2.

3. Only then I reinstalled everything before I submit this post, to make sure I hadn't corrupted anything in my own versions.

[ Edit - End ]

I also searched for the header arm_acle.h listed in the error message - the only file with that name on my entire Mac appears only within an Python Anaconda package which seems to be completely independent from QT or from the application I am building (which is in C++ btw).
I'm quite new to the topic of building apps so it's difficult for me to narrow-down the steps to reproduce the issue.
Just in case, here is the full instruction from the project's owner (the versions listed in the instruction are older, but the same methodology worked with MacOSX26.2 and QT 6.10.2).

I would be very glad to hear of any hint to resolve this issue.

Christian Ehrlicher

@NW135 said in qmake/nmake fails on MacOSX26.4 with Qt 6.11 with error implicitly declaring library function '__yield':

do you happen to know when (approximately) the fix will be made available through the online installer?

As you can see in the bug report it's fixed for 6.11.1 and 6.12

I don't feel able to incorporate this safely in my own installation,

It's just 5 lines in a header file: https://codereview.qt-project.org/c/qt/qtbase/+/725069

Christian Ehrlicher

@NW135 said in qmake/nmake fails on MacOSX26.4 with Qt 6.11 with error implicitly declaring library function '__yield':

include the header <arm_acle.h>

Did you try what the compiler tells you? Add it to qyieldcpu.h

NW135

Many thanks for your prompt answer, this is appreciated.

I didn't try from the beginning, because qyieldcpu.h is a file provided by the QT installer, I would not expect that it would be required to modify the QT's source for what should be a routine task.

However, based on your hint, I just tried now and get a cascade of errors:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:21:2: error: 
      "ACLE intrinsics support not enabled."
   21 | #error "ACLE intrinsics support not enabled."
      |  ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:60:9: error: 
      use of undeclared identifier '__builtin_arm_ldrex'; did you mean
      '__builtin_ia32_lddqu'?
   60 |     v = __builtin_arm_ldrex(__p);
      |         ^~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:60:29: error: 
      cannot initialize a parameter of type 'const char *' with an lvalue of
      type 'volatile uint32_t *' (aka 'volatile unsigned int *')
   60 |     v = __builtin_arm_ldrex(__p);
      |                             ^~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:61:10: error: 
      use of undeclared identifier '__builtin_arm_strex'
   61 |   while (__builtin_arm_strex(__x, __p));
      |          ^~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:91:3: error: 
      use of undeclared identifier '__builtin_arm_nop'; did you mean
      '__builtin_trap'?
   91 |   __builtin_arm_nop();
      |   ^~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:127:10: error: 
      use of undeclared identifier '__builtin_arm_clz'
  127 |   return __builtin_arm_clz(__t);
      |          ^~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:135:10: error: 
      use of undeclared identifier '__builtin_arm_clz64'
  135 |   return __builtin_arm_clz64(__t);
      |          ^~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:141:10: error: 
      use of undeclared identifier '__builtin_arm_clz64'
  141 |   return __builtin_arm_clz64(__t);
      |          ^~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:147:10: error: 
      use of undeclared identifier '__builtin_arm_cls'
  147 |   return __builtin_arm_cls(__t);
      |          ^~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:155:10: error: 
      use of undeclared identifier '__builtin_arm_cls64'
  155 |   return __builtin_arm_cls64(__t);
      |          ^~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:161:10: error: 
      use of undeclared identifier '__builtin_arm_cls64'
  161 |   return __builtin_arm_cls64(__t);
      |          ^~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:213:10: error: 
      use of undeclared identifier '__builtin_arm_rbit'
  213 |   return __builtin_arm_rbit(__t);
      |          ^~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:222:10: error: 
      use of undeclared identifier '__builtin_arm_rbit64'
  222 |   return __builtin_arm_rbit64(__t);
      |          ^~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:595:10: error: 
      use of undeclared identifier '__builtin_arm_crc32b'
  595 |   return __builtin_arm_crc32b(__a, __b);
      |          ^~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:600:10: error: 
      use of undeclared identifier '__builtin_arm_crc32h'; did you mean
      '__builtin_ia32_crc32hi'?
  600 |   return __builtin_arm_crc32h(__a, __b);
      |          ^~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:605:10: error: 
      use of undeclared identifier '__builtin_arm_crc32w'
  605 |   return __builtin_arm_crc32w(__a, __b);
      |          ^~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:610:10: error: 
      use of undeclared identifier '__builtin_arm_crc32d'; did you mean
      '__builtin_ia32_crc32di'?
  610 |   return __builtin_arm_crc32d(__a, __b);
      |          ^~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:595:10: note: 
      '__builtin_ia32_crc32di' declared here
  595 |   return __builtin_arm_crc32b(__a, __b);
      |          ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:615:10: error: 
      use of undeclared identifier '__builtin_arm_crc32cb'
  615 |   return __builtin_arm_crc32cb(__a, __b);
      |          ^~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/include/arm_acle.h:620:10: error: 
      use of undeclared identifier '__builtin_arm_crc32ch'
  620 |   return __builtin_arm_crc32ch(__a, __b);
      |          ^~~~~~~~~~~~~~~~~~~~~
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.

Sounds like something that should be better placed in more expert hands than mine...

Christian Ehrlicher

@NW135 said in qmake/nmake fails on MacOSX26.4 with Qt 6.11 with error implicitly declaring library function '__yield':

, I would not expect that it would be required to modify the QT's source for what should be a routine task.

What routine task? You're using a very recent toolchain which came out after 6.11.0 was tagged...
It was just a try to see if it can be fixed locally as there is for sure already a bug report for it as you can see here: https://qt-project.atlassian.net/browse/QTBUG-145239

The fix is also trivial to add to your local Qt installation.

NW135

Thank you for pointing me to the recent bug report - for my convenience, do you happen to know when (approximately) the fix will be made available through the online installer?

Reading the fix description, I don't feel able to incorporate this safely in my own installation, at least with my modest knowledge. Your recommendation is welcome whether I'm just missing some obvious piece of information or I should wait for a regular update.

With "routine task", I was meaning "building a project" - agreed the versions are recent, but if I understand they are stable releases (not beta). This was just to explain why I didn't try this first hand - I understand also that your recommendation aimed at circumventing the issue.

In fact, I put an edit in my initial post; the information I have tends to confirm that the issue was triggered by the recent MacOS update rather than QT 6.11, as stated in the bug description.

Christian Ehrlicher

@NW135 said in qmake/nmake fails on MacOSX26.4 with Qt 6.11 with error implicitly declaring library function '__yield':

do you happen to know when (approximately) the fix will be made available through the online installer?

As you can see in the bug report it's fixed for 6.11.1 and 6.12

I don't feel able to incorporate this safely in my own installation,

It's just 5 lines in a header file: https://codereview.qt-project.org/c/qt/qtbase/+/725069

NW135

@Christian-Ehrlicher said in qmake/nmake fails on MacOSX26.4 with Qt 6.11 with error implicitly declaring library function '__yield':

As you can see in the bug report it's fixed for 6.11.1 and 6.12

... which means, according to this page, some time before September 2026.

@Christian-Ehrlicher said in qmake/nmake fails on MacOSX26.4 with Qt 6.11 with error implicitly declaring library function '__yield':

It's just 5 lines in a header file

When reading that same description, I was struggling at which file and which 5 lines to adjust, eventually I solved the issue on my own installation by editing qyieldcpu.h (the very same file and path provided in the compiler message) as follows (my changes are located before comments beginning with FIX):

#if __has_builtin(__builtin_arm_yield) // FIX moved from below and replaced elif by if
    __builtin_arm_yield();
#elif __has_builtin(__yield) // FIX replaced if with elif
    __yield();              // Generic
#elif defined(_YIELD_PROCESSOR) && defined(Q_CC_MSVC)
    _YIELD_PROCESSOR();     // Generic; MSVC's <atomic>
// ... elided a few other unchanged lines here
#elif defined(Q_PROCESSOR_X86)
    __asm__("pause");           // hopefully asm() works in this compiler
// FIX moved __has_builtin(__builtin_arm_yield to the top

I was able to test successfully on my own machine, yet no clue what this means and implies.

I hope this information may be useful for other users in a similar situation.

In any case, many thanks for the fast answer and the prompts which helped me address the concern.