Opened 7 weeks ago

Last modified 4 days ago

#69632 assigned defect

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

Reported by: barracuda156 Owned by: catap (Kirill A. Korinsky)
Priority: Normal Milestone:
Component: ports Version: 2.9.1
Keywords: sonoma Cc: Dave-Allured (Dave Allured), cquike
Port: gcc10-bootstrap

Description

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?

Change History (12)

comment:1 Changed 4 weeks ago by Dave-Allured (Dave Allured)

Cc: Dave-Allured added

comment:2 Changed 4 weeks ago by 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).

comment:3 Changed 4 weeks ago by 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.

comment:4 Changed 4 weeks ago by 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.

comment:5 Changed 4 weeks ago by 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.

comment:6 Changed 4 weeks ago by 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.

comment:7 in reply to:  4 ; Changed 4 weeks ago by 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.

comment:8 in reply to:  7 Changed 4 weeks ago by 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 :(

comment:9 Changed 4 weeks ago by 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…

Last edited 4 weeks ago by kencu (Ken) (previous) (diff)

comment:10 Changed 4 weeks ago by 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.

Last edited 4 weeks ago by kencu (Ken) (previous) (diff)

comment:11 Changed 4 days ago by 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?

comment:12 in reply to:  11 Changed 4 days ago by ryandesign (Ryan Carsten Schmidt)

Cc: cquike added

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.

Note: See TracTickets for help on using tickets.