Skip to content

Instantly share code, notes, and snippets.

@scivision
Last active April 25, 2025 15:09
Show Gist options
  • Save scivision/d69faebbc56da9714798087b56de925a to your computer and use it in GitHub Desktop.
Save scivision/d69faebbc56da9714798087b56de925a to your computer and use it in GitHub Desktop.
Xcode 16 Homebrew GCC 14.2 breaks with CMake

Sometimes upon updating macOS, the Xcode SDK becomes incompatible with Homebrew GCC. Sometimes the problem is that the "Command Line Tools" are too new for the Homebrew GCC. Sometimes the problem is the the Xcode SDK hasn't installed the latest "command line tools".

Note, the examples below use "g++-14" -- substitute the appropriate GCC version if we haven't updated this document.

Ensure Command Line Tools matches macOS, Xcode and Homebrew Config

Determine the Xcode version by

brew config

Note that the Xcode version in general is different from the macOS version. The SDK version is the same as the macOS version. Determine the macOS version by

sw_vers -productVersion

Determine the default Command Line Tools version, and other versions available by

ls -l /Library/Developer/CommandLineTools/SDKs

Check that the Command Line Tools of the Xcode version are installed by

softwareupdate --list

If needed, update the Command Line Tools from the softwareupdate --list command like (substitute the appropriate version number):

softwareupdate -i "Command Line Tools for Xcode-16.3"

Open the Xcode App itself to accept the license and complete the installation.

If this still doesn't work to get the Command Line Tools to match the Xcode version, then download the Command Line Tools for the Xcode version and install them manually.

If these all fail, then consider reinstalling Homebrew--this is uncommon but sometimes necessary after a macOS update.

Test compatibility

Homebrew GCC and Xcode SDK incompatibilites may be revealed in this simple project. If the

CXX=g++-14 cmake -Bbuild --fresh

cmake --build build

Workaround

The workaround is to specify SDKROOT so that CMake uses the compatible SDK with GCC 14.2, until Homebrew updates its platform environment. Create a file ~/gcc.sh and source ~/gcc.sh to use GCC:

export CC=gcc-14 CXX=g++-14 FC=gfortran-14

export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/

In general in my projects I have CMake print CMAKE_OSX_SYSROOT so when users run into an issue I can help them more quickly.

Configure output

CXX=g++-14 SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/ cmake -Bbuild --fresh
-- The CXX compiler identification is GNU 14.2.0
...
-- CMAKE_OSX_SYSROOT /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk
-- OS_NAME: macOS
-- OS_RELEASE: 15.4.1
-- OS_PLATFORM: arm64

GCC + Xcode build errors

Build errors if using CMake with Xcode incompatible with Homebrew GCC:

/opt/homebrew/bin/g++-14   -O3 -DNDEBUG -arch arm64 -MD -MT CMakeFiles/main.dir/main.cpp.o -MF CMakeFiles/main.dir/main.cpp.o.d -o CMakeFiles/main.dir/main.cpp.o

/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/mach/arm/_structs.h:627:35: error: expected primary-expression before 'unsigned'
  627 | } __attribute__((aligned(_Alignof(unsigned int))));
      |

or

/opt/homebrew/bin/g++-14   -O3 -DNDEBUG -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.0.sdk -MD -MT CMakeFiles/main.dir/main.cpp.o -MF CMakeFiles/main.dir/main.cpp.o.d -o CMakeFiles/main.dir/main.cpp.o

/opt/homebrew/Cellar/gcc/14.2.0/lib/gcc/current/gcc/aarch64-apple-darwin23/14/include-fixed/stdio.h:83:8: error: 'FILE' does not name a type
   83 | extern FILE *__stdinp;
      |        ^~~~
/opt/homebrew/Cellar/gcc/14.2.0/lib/gcc/current/gcc/aarch64-apple-darwin23/14/include-fixed/stdio.h:81:1: note: 'FILE' is defined in header '<cstdio>'; this is probably fixable by adding '#include <cstdio>'
   80 | #include <sys/_types/_seek_set.h>
  +++ |+#include <cstdio>
   81 |

Regular command line is OK

g++-14 main.cpp -v

works, output ends with

 /opt/homebrew/Cellar/gcc/14.2.0/bin/../libexec/gcc/aarch64-apple-darwin23/14/collect2 -demangle -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/ -dynamic -arch arm64 -platform_version macos 15.0.0 0.0 -o a.out -L/opt/homebrew/Cellar/gcc/14.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin23/14 -L/opt/homebrew/Cellar/gcc/14.2.0/bin/../lib/gcc/current/gcc -L/opt/homebrew/Cellar/gcc/14.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin23/14/../../.. -lemutls_w -lheapt_w /var/folders/dh/k7c2gppn12v3w0plnf_xz94c0000gn/T//ccarxhZd.o -lstdc++ -lgcc -lSystem -no_compact_unwind -rpath @loader_path -rpath /opt/homebrew/Cellar/gcc/14.2.0/lib/gcc/current/gcc/aarch64-apple-darwin23/14 -rpath /opt/homebrew/Cellar/gcc/14.2.0/lib/gcc/current/gcc -rpath /opt/homebrew/Cellar/gcc/14.2.0/lib/gcc/current
cmake_minimum_required(VERSION 3.20)
project(min LANGUAGES CXX)
set(CMAKE_CXX_SCAN_FOR_MODULES OFF)
# set OFF if not using C++ modules, or it can trip similar compiler errors due to "-fmodules-ts" flags auto-added when ON.
message(STATUS "CMAKE_OSX_SYSROOT ${CMAKE_OSX_SYSROOT}")
foreach(i IN ITEMS OS_NAME OS_VERSION OS_RELEASE OS_PLATFORM)
cmake_host_system_information(RESULT ${i} QUERY ${i})
message(STATUS "${i}: ${${i}}")
endforeach()
add_executable(main main.cpp)
file(GENERATE OUTPUT .gitignore CONTENT "*")
#include <iostream>
int main(){ return 0; }
@benhaub
Copy link

benhaub commented Sep 20, 2024

It broke in the same way for me on gcc@12. This helped me out. Thanks!

@PKua007
Copy link

PKua007 commented Oct 5, 2024

Is there an original issue from Homebrew/GCC somewhere? If so, it would be helpful to link it - I landed here by searching for a general issue, not specifically connected with the scivision project

@saschasc
Copy link

saschasc commented Oct 6, 2024

@PKua007 Most likely this is the current issue on iains gcc-14 branch.
iains/gcc-14-branch#11

Not sure however who will take care to bring this to Homebrew as soon as fixed.

@SeppeStaelens
Copy link

Was stuck on this for hours - the export commands you mentioned resolved it! A million thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment