gcc10-bootstrap does not work on 14.4.1: error: missing ')' after "__has_attribute"

[barracuda156]

Since the current Apple clang cannot build gcc on Sonoma #69631 I have tried to build it with gcc10-bootstrap. It seems not to work either, but failing already at configure:

configure:4506: checking whether the C compiler works
configure:4528: /opt/local/libexec/gcc10-bootstrap/bin/gcc -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk conftest.c  >&5
configure:4532: $? = 0
configure:4580: result: yes
configure:4583: checking for C compiler default output file name
configure:4585: result: a.out
configure:4591: checking for suffix of executables
configure:4598: /opt/local/libexec/gcc10-bootstrap/bin/gcc -o conftest -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk conftest.c  >&5
configure:4602: $? = 0
configure:4624: result: 
configure:4646: checking whether we are cross compiling
configure:4654: /opt/local/libexec/gcc10-bootstrap/bin/gcc -o conftest -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk conftest.c  >&5
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/_stdio.h:68,
                 from /opt/local/libexec/gcc10-bootstrap/lib/gcc/aarch64-apple-darwin23/10.5.0/include-fixed/stdio.h:78,
                 from conftest.c:9:
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/cdefs.h:554:30: error: missing ')' after "__has_attribute"
  554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage)
      |                              ^~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/cdefs.h:554:32: error: missing binary operator before token "unsafe_buffer_usage"
  554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage)
      |                                ^~~~~~~~~~~~~~~~~~~
configure:4658: $? = 1
configure:4665: ./conftest
/opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_lang_gcc-devel/libgcc-devel/work/gcc-14-20240324/configure: line 4667: ./conftest: No such file or directory
configure:4669: $? = 127
configure:4676: error: in `/opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_lang_gcc-devel/libgcc-devel/work/build':
configure:4678: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

Am I doing something wrong?

[ryandesign (Ryan Carsten Schmidt)]

It strikes me as never a good idea when projects (like gcc here) try to replace standard system headers (like stdio.h here) with their own version. This can only end badly (as it did here).

[ryandesign (Ryan Carsten Schmidt)]

Or replacing stdio.h may not be the problem. I see from the error that gcc doesn't like the use of __has_cpp_attribute in cdefs.h, specifically the fact that the value being checked contains a :. This problem was also reported here: ​https://forums.developer.apple.com/forums/thread/747762

This may be a bug in the system headers that makes them clang-specific. It may be a bug in gcc that it does not recognize attribute names containing a :. I don't know whether attribute names are defined as being allowed to contain a : or not. In any case, it's not uncommon to have problems compiling with gcc on modern clang-based macOS and the usual advice if you want to avoid such headaches is Don't Do That. Use clang.

[ryandesign (Ryan Carsten Schmidt)]

In the forum thread, it says gcc 11, 12, and 13 don't have this problem, so maybe it was a gcc bug that was already fixed. Try a newer gcc.

[ryandesign (Ryan Carsten Schmidt)]

It looks like ​this commit which landed in gcc 11.1 is where the has-attribute code was adjusted to allow scopes (::) in C code.

[catap (Kirill A. Korinsky)]

I agree that replacing headers isn't good idea at all.

I try to find some time to test this gcc on sonoma in this or next week, and special to test pointed commit.

[barracuda156]

Replying to ryandesign:

In the forum thread, it says gcc 11, 12, and 13 don't have this problem, so maybe it was a gcc bug that was already fixed. Try a newer gcc.

Well, trying a newer gcc is not a solution here, since this is the only bootstrap gcc version we got.

[catap (Kirill A. Korinsky)]

Replying to barracuda156:

Replying to ryandesign:

In the forum thread, it says gcc 11, 12, and 13 don't have this problem, so maybe it was a gcc bug that was already fixed. Try a newer gcc.

Well, trying a newer gcc is not a solution here, since this is the only bootstrap gcc version we got.

pointed commit won't be complicated to backport.

Anyway, it may turns that it requires something else, and rebuild GCC is a few hours :(

[kencu (Ken)]

the planned role for gcc10-bootstrap doesn’t require it to build on new systems.

trying to keep gcc10-bootstrap building against ever-newer MacOS SDKs will be a difficult, mess, time-consuming y project….without much of a point to it…. and there is so much else to do instead, like fixing the gstreamer ports, for example…

[kencu (Ken)]

If the current clang with the current SDK won’t bootstrap the current gcc at the moment, bootstrapping some older gcc instead will inevitably be even harder. Iain is constantly updating his active gcc branch to take into account changes in newer SDKs.

[cquike]

I have a (maybe) related problem. This is with gcc-13 actually but the error message is the same:

$ cat test.c
#include <stdio.h>
$ /opt/local/bin/gcc-mp-13   -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk  -std=c99   -c test.c
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/_stdio.h:68,
                 from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/stdio.h:64,
                 from j.c:1:
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/cdefs.h:554:30: error: missing ')' after "__has_attribute"
  554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage)
      |                              ^
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/cdefs.h:554:31: error:  ':' without preceding '?'
  554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage)

It seems that the -std=c99 flag is crucial to get the error. Omitting it does not cause the error. Has anyone any workaround for this problem?

[ryandesign (Ryan Carsten Schmidt)]

Replying to barracuda156:

Replying to ryandesign:

In the forum thread, it says gcc 11, 12, and 13 don't have this problem, so maybe it was a gcc bug that was already fixed. Try a newer gcc.

Well, trying a newer gcc is not a solution here, since this is the only bootstrap gcc version we got.

Sure it is. You are experiencing a bug that was fixed in a later version of gcc than the one you are using. The solution is to use the newer version of gcc. We have a gcc11 port. If that's not satisfactory and you need it to be a "bootstrap" version, then create a gcc11-bootstrap (or newer) port.

Replying to catap:

pointed commit won't be complicated to backport.

I'm not wild about backporting more and more bug fixes to older compilers. At some point, gcc 10 with a bunch of patches can no longer be considered gcc 10. If you want gcc 10, bugs and all, then use gcc 10. If you don't want the bugs that were fixed in newer versions, then use the newer versions.

Replying to cquike:

I have a (maybe) related problem. This is with gcc-13 actually but the error message is the same:

$ cat test.c
#include <stdio.h>
$ /opt/local/bin/gcc-mp-13   -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk  -std=c99   -c test.c
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/_stdio.h:68,
                 from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/stdio.h:64,
                 from j.c:1:
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/cdefs.h:554:30: error: missing ')' after "__has_attribute"
  554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage)
      |                              ^
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/cdefs.h:554:31: error:  ':' without preceding '?'
  554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage)

It seems that the -std=c99 flag is crucial to get the error. Omitting it does not cause the error. Has anyone any workaround for this problem?

Then evidently gcc in C99 mode is not compatible with macOS 14 headers. Your options are not to use C99 mode or not to use gcc.

[ryandesign (Ryan Carsten Schmidt)]

This issue is also discussed in #70209 where it is said that it is fixed in gcc 13.3 and 12.4. This is the gcc bug:

​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007

This is the commit that fixed it for 13:

​https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=051cd2a3ee9ba9f47d640a10e96c79b6c5124736

and this commit for 12:

​https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=c2cd5eefccf54074ea9f8dc677a9a05b8a880ae4

[ryandesign (Ryan Carsten Schmidt)]

gcc12 was updated to 12.4.0 in [b4b607553d56abe9fac035f4f71fee388b6a50ce/macports-ports].

gcc13 was updated to 13.3.0 in [7206de1eb57afa392179e61130207bab5cf064f0/macports-ports].

[barracuda156]

Replying to ryandesign:

Well, trying a newer gcc is not a solution here, since this is the only bootstrap gcc version we got.

Sure it is. You are experiencing a bug that was fixed in a later version of gcc than the one you are using. The solution is to use the newer version of gcc. We have a gcc11 port. If that's not satisfactory and you need it to be a "bootstrap" version, then create a gcc11-bootstrap (or newer) port.

There was a reason to choose gcc10 specifically, since it is the last GCC which does not require C++11 to build. There is no meaningful case to justify any other bootstrap gcc, we should rather backport the fix to gcc10-bootstrap (or wait until Iain updates his branch was then pull in his patches).