brew install gcc fails on macOS 14.3.1 and CLT 15.3

[ilg-ul]

I just updated my Intel Mac and I noticed that the HomeBrew GCC build failed:

ilg@wksi ~ % brew install gcc
...
==> Applying gcc-xcode15-warnings.diff
patching file 'gcc/config/aarch64/darwin.h'
patching file 'libgfortran/libgfortran.spec.in'
==> ../configure --prefix=/Users/ilg/.local/homebrew/hb/opt/gcc --libdir=/Users/
==> make
Last 15 lines from /Users/ilg/Library/Logs/Homebrew/gcc/02.make:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/c++/v1/__format/formatter_bool.h:20:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/c++/v1/__format/formatter_integral.h:32:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/c++/v1/locale:202:
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/c++/v1/__locale:813:5: error: expected expression
    return std::use_facet<ctype<_CharT> >(__loc).is(ctype_base::cntrl, __c);
    ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make[3]: *** [cp/mapper-resolver.o] Error 1
20 errors generated.
make[3]: *** [cp/module.o] Error 1
rm gcc.pod
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

Do not report this issue to Homebrew/brew or Homebrew/homebrew-core!

Please note that brew is installed in the home folder (/Users/ilg/.local/homebrew/hb), not in system locations.

[ilg-ul]

Also please note that CLT 14.3.1 refuses to install on macOS 14.3.1, so reverting to my previous setup is no longer possible. (I partly bricked my machine).

[Bo98]

15.3 does have some incompatibilities when using GCC, so very likely has issues compiling it too. But you can try 15.1 (there is no CLT 15.2). With that said, can you do brew gist-logs gcc (or upload ~/Library/Logs/Homebrew/gcc/02.make somewhere) as I think there's more information from the build error log missing here.

[grobian]

This can be worked around, ugly as hell, but it works. https://gitweb.gentoo.org/repo/proj/prefix.git/patch/?id=bf8c6e96498309932dbdc975462ef93eb0c1c347

(You don't need this hack if you're compiling from an (older) GCC, and you're using libstdc++, because then the CLT headers aren't used.)

[ilg-ul]

But you can try 15.1 ...

Thank you @Bo98, reverting to 15.1 helped, the build passed.

ilg@wksi ~ % gcc-13 --version
gcc-13 (Homebrew GCC 13.2.0) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ilg@wksi ~ % which gcc-13
/Users/ilg/.local/homebrew/hb/bin/gcc-13
ilg@wksi ~ % 

[iains]

I believe this is fixed on trunk, and hopefully it will be possible to back port it for 13.3, if that is not possible then we will surely be able to add the patch to my Darwin/macOS branch

[iains]

in the short-term, this is the patch to back port (if using 15.1 is not viable for you): https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=9970b576b7e4ae337af1268395ff221348c4b34a

note, there are some other potential issues in building libcc1 - but they should not fire in a bootstrap build.

[grobian]

thanks!

[ilg-ul]

we will surely be able to add the patch to my Darwin/macOS branch

For my xPack GCC builds I use the HomeBrew patches, so if you add the patch to your branch and HB updates the gcc script, I'll get everything from there.

[grobian]

FYI the patch is not enough, the build still fails like this:

In file included from /Volumes/Storage/Gentoo/bootstrap64-20240313/tmp/var/tmp/portage/sys-devel/gcc-13.2.0/work/gcc-13-branch-gcc-13.2-darwin-r0/libcc1/libcp1plugin.cc:74:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/vector:321:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__format/formatter_bool.h:20:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__format/formatter_integral.h:32:   
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/locale:289:36: error: attempt to use a poisoned identifier
        __status = (unsigned char*)malloc(__nkw);
                                   ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/locale:1584:28: error: attempt to use a poisoned identifier
        __ob = (char_type*)malloc(2*static_cast<size_t>(__nc)*sizeof(char_type));
                           ^

[iains]

Is this because you are trying to do a --disable-bootstrap with clang as the host compiler?

that is not really the best course of action , if the host compiler is not GCC-13, you should bootstrap.

However, the issue with libcc1 is also known and a patch proposed, but not yet applied (I think)

[grobian]

Yes, I'm doing --disable-bootstrap, which is ugly. I should indeed only skip the bootstrap when the in use compiler is already the same GCC. Sorry for the noise.

[iains]

1. NP: but the "Right Way" to save time on frequent (or debug) builds is to bootstrap the compiler once and then use that in --disable-boostrap (it will ensure that you are building with support for the current builtins, and that the libstdc++ will be statically linked into the compiler exectuables - amongst other things). I am sure we will fix the problem you've seen, but the --disable-bootstrap with a "foreign" host compiler is just Not Tested™ - which might well eat up all the time you saved in solving incidental issues ;)

[Bo98]

There will be issues using GCC 13 with the newer SDK as well, such as echo "#include <TargetConditionals.h>" | gcc-13 -E - but most of these issues are fixed in GCC 14 and will be a case of figuring out how best to fix older versions.

[ilg-ul]

It would be great to find a way to fix older versions too, if possible.

[iains]

If there is Darwin-critical stuff that cannot be backported to the upstream branch(es), then I will expect to keep it on the Darwin/macOS I maintain (this obviously includes the Arm64 support). In most cases it is not 'rocket science' but does take time to do and test.

[Bo98]

TargetConditionals.h fix in GCC 14 is implementing __has_extension but given that's a new feature rather than a bug fix I imagine for older versions that would be a fixincludes job instead? Not entirely sure how that works given that would not exactly be a backport.

[iains]

TargetConditionals.h fix in GCC 14 is implementing __has_extension but given that's a new feature rather than a bug fix I imagine for older versions that would be a fixincludes job instead? Not entirely sure how that works given that would not exactly be a backport.

that's an example of where a "Vendor Branch" is useful - since it's a new feature (so not eligible for back port) but something we might regard as critical (and the CHERI folks too, I expect). However, I'd like to keep the number of things we maintain separately to the minimum since that is all extra work.

[iains]

I believe this is fixed in 13.3-darwin-r0