[clang] Driver does not select a default -isysroot when targeting macOS

[bradking]

On most platforms, clang hello.c works out of the box for builds targeting the host platform. However, as of LLVM/Clang 20.1.2, this is not the case on macOS:

$ cat main.c
int main(void) { return 0; }
$ clang main.c
ld: library 'System' not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)
$ cat hello.c
#include <stdio.h>
int main(void) { printf("Hello, world!"); return 0; }
$ clang hello.c
hello.c:1:10: fatal error: 'stdio.h' file not found
    1 | #include <stdio.h>
      |          ^~~~~~~~~
1 error generated.

Instead one must manually populate the SDKROOT environment variable (or pass -isysroot):

$ export SDKROOT="$(xcrun --sdk macosx --show-sdk-path)"
$ clang main.c
$ clang hello.c

It seems reasonable to expect clang to select a default sysroot automatically on macOS even when SDKROOT is not set in the environment.

[bradking]

I see relevant code here that could perhaps be taught to ask xcrun for the default SDK path.

[bradking]

For reference, CMake users have been sheltered from this problem prior to CMake 4.0 because it selected a default CMAKE_OSX_SYSROOT automatically. However, CMake 4.0's release notes state:

• Builds targeting macOS no longer choose any SDK or pass an -isysroot flag to the compiler by default. Instead, compilers are expected to choose a default macOS SDK on their own. In order to use a compiler that does not do this, users must now specify CMAKE_OSX_SYSROOT when configuring their build, e.g., -DCMAKE_OSX_SYSROOT=macosx.

In general CMake expects the toolchain to support $CC hello.c out of the box. The only reason CMake ever gained a default CMAKE_OSX_SYSROOT was because it was needed even with macOS system compilers /usr/bin/{cc,c++} for a brief period around the macOS 10.8 days. Then it was kept for compatibility until a major version bump, which has now arrived.

CMake Issue 26863 tracks this problem for users of upstream LLVM/Clang with CMake.

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: Brad King (bradking)

On most platforms, `clang hello.c` works out of the box for builds targeting the host platform. However, as of LLVM/Clang 20.1.2, this is not the case on macOS:

$ cat main.c
int main(void) { return 0; }
$ clang main.c
ld: library 'System' not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)
$ cat hello.c
#include <stdio.h>
int main(void) { printf("Hello, world!"); return 0; }
$ clang hello.c
hello.c:1:10: fatal error: 'stdio.h' file not found
    1 | #include <stdio.h>
      |          ^~~~~~~~~
1 error generated.

Instead one must manually populate the SDKROOT environment variable (or pass -isysroot):

$ export SDKROOT="$(xcrun --sdk macosx --show-sdk-path)"
$ clang main.c
$ clang hello.c

It seems reasonable to expect clang to select a default sysroot automatically on macOS even when SDKROOT is not set in the environment.

[nico]

Lots of discussion about this in https://reviews.llvm.org/D136315 a while ago.

[nico]

(…and while this is a nice quality of life feature for compiler devs using HEAD clang for local stuff, if you have a meta build system (especially one that needs a comparatively long time to run to do its thing), isn't it conceptually nicer if the meta build system figured out the toolchain path once, instead of every compiler invocation having to do it?)

[ADKaster]

Lots of discussion about this in https://reviews.llvm.org/D136315 a while ago.

Pulling on that thread, I think that makes this technically a dup of #45225 ?

Albeit with more of the upstream CMake use case outlined. The last Pull Request linked from 45225 seems to be from a homebrew maintainer.

[bradking]

CMake MR 10734 teaches CMake to detect when Clang has no default sysroot and add its own -isysroot based on xcrun --show-sdk-path when CMAKE_OSX_SYSROOT is empty, thus resolving CMake Issue 26863. It is scheduled to be included in the CMake 4.0.2 release.

That resolves the immediate problem for CMake users. However, I still think this should be resolved on the LLVM/Clang side too, so I'll leave this open for now.