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, messy, time-consuming 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.