Missing standard includes on macOS runners

[csparker247]

Description

I just started testing my project against the macOS runners and got a lot of missing includes from the MacOS SDKs. For example:

/Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/cstddef:59:9: error: no member named 'nullptr_t' in the global namespace
using ::nullptr_t;
      ~~^
In file included from /Users/runner/work/volume-cartographer/volume-cartographer/build/_deps/smgl-src/smgl/src/Logging.cpp:1:
In file included from /Users/runner/work/volume-cartographer/volume-cartographer/build/_deps/smgl-src/smgl/include/smgl/Logging.hpp:3:
In file included from /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/ostream:168:
In file included from /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/__memory/shared_ptr.h:22:
In file included from /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/__memory/allocation_guard.h:14:
In file included from /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/__memory/allocator_traits.h:14:
In file included from /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/__memory/construct_at.h:23:
In file included from /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/new:96:
/Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/cstdlib:90:5: error: <cstdlib> tried including <stdlib.h> but didn't find libc++'s <stdlib.h> header.           This usually means that your header search paths are not configured properly.           The header search paths should contain the C++ Standard Library headers before           any C Standard Library, and you are probably using compiler flags that make that           not be the case.
#   error <cstdlib> tried including <stdlib.h> but didn't find libc++'s <stdlib.h> header. \

This is very similar to an issue I had 4 years ago, so I know that this is some sort of Xcode/SDK configuration error. In this case, I solved my build problems by explicitly using the command line tools and not Xcode:

      - name: Use the Command Line Tools
        run: |
          sudo xcode-select -s /Library/Developer/CommandLineTools

I don't know if this is a regression in the macOS runner images or just a perpetual problem with Xcode, so I thought I'd at least record it here for posterity.

macos-13 job log [link]
macos-14 job log [link]

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• Ubuntu 24.04
• macOS 11
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• Windows Server 2019
• Windows Server 2022

Image version and build link

macos-13 runner version: 2.317.0
macos-14 runner version: 2.317.0

Is it regression?

unknown

Expected behavior

Successful build.

Actual behavior

Build fails with errors pertaining to missing includes/unknown symbols from the C++ standard libraries.

Repro steps

My old test repository has a minimal example using ITK: https://github.com/csparker247/cpp-build-action

[erik-bershel]

Hey @csparker247!

Thank you for bringing it to other users attention. Yes, such a problem exists. Depends on the version of XCode and the version of macOS on which it is installed, oddly enough. Unfortunately, this is behaviour that we cannot control and the only available solution is to manually choose the SDK (or only some set of libraries in some cases) used on the users' side. In any case, during installation we download all available ones, including those that come with CommandLineTools. We would not like to install additional versions, since we will still never be able to provide a solution in this area that satisfies all users and it will be easier and faster to download or link them on the go.
Another example of such changes: #9976