# CMAKE\_OSX\_SYSROOT does not guide compiler selection
**URL:** https://discourse.cmake.org/t/cmake-osx-sysroot-does-not-guide-compiler-selection/4872
**Category:** Development
**Tags:** os:macos
**Created:** [January 18, 2022, 11:54pm UTC](https://discourse.cmake.org/t/cmake-osx-sysroot-does-not-guide-compiler-selection/4872 "2022-01-18T23:54:44Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@JoeM](https://discourse.cmake.org/u/JoeM)
#### Post date: [January 18, 2022, 11:54pm UTC](https://discourse.cmake.org/t/cmake-osx-sysroot-does-not-guide-compiler-selection/4872/1 "2022-01-18T23:54:44Z")
The documentation for this variable explains:
> Specify the location or name of the macOS platform SDK to be used. CMake uses this value to compute the value of the `-isysroot` flag or equivalent and to help the `find_*` commands locate files in the SDK.
However, when determining the real path to the compiler, CMakeDetermineCompiler.cmake is using `xcrun -find cc` (for example) on Apple platforms. This ignores any SDK preference as specified by CMAKE\_OSX\_SYSROOT. The SDK will have a settings file which directs xcrun to the toolchain to use with that SDK. What the .cmake code should do is include `-sdk ${CMAKE_OSX_SYSROOT}` when that variable is set.
It’s worth noting further that as result, you get different build behavior/results when using make/Ninja as the generator, versus using Xcode. Xcode follows the SDK settings to find the compiler from the linked toolchain. I noticed an Xcode generator build doesn’t even encode a CMAKE\_C\_COMPILER in the cache. I guess it leaves it to xcodebuild to drive that?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [January 21, 2022, 1:41pm UTC](https://discourse.cmake.org/t/cmake-osx-sysroot-does-not-guide-compiler-selection/4872/2 "2022-01-21T13:41:07Z")
Usually, I’ve used `DEVELOPER_DIR` to guide compiler selection and `CMAKE_OSX_SYSROOT` for which SDK to compile with. I don’t think that the documentation for that variable really has any effect on compiler detection (which rarely (never?) uses `find_*` anyways).
The Xcode difference is that Xcode has a slot to say “what compiler to use” while CMake needs to generate command lines on its own for `make` and `ninja`.
---
### Author:  [@JoeM](https://discourse.cmake.org/u/JoeM)
#### Post date: [February 11, 2022, 12:20am UTC](https://discourse.cmake.org/t/cmake-osx-sysroot-does-not-guide-compiler-selection/4872/3 "2022-02-11T00:20:48Z")
I’ve learned that this is a facet of the internal SDKs we use for development @Apple. There’s a feature built in to the SDK configuration that guides the compiler selection. I found that I could get the correct behavior by updating
```auto
# Look for a make tool provided by Xcode
if(CMAKE_HOST_APPLE)
macro(_query_xcrun compiler_name result_var_keyword result_var)
if(NOT "x${result_var_keyword}" STREQUAL "xRESULT_VAR")
message(FATAL_ERROR "Bad arguments to macro")
endif()
execute_process(COMMAND xcrun --find ${compiler_name}
OUTPUT_VARIABLE _xcrun_out OUTPUT_STRIP_TRAILING_WHITESPACE
ERROR_VARIABLE _xcrun_err)
```
to add -sdk to the xcrun command line when $CMAKE\_OSX\_SYSROOT is configured. This is in `share/cmake/Modules/CMakeDetermineCompiler.cmake`.
I know this only affects a small set of users doing development w/ CMake here but it’d be great to figure out a fix that could be upstreamed.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [February 14, 2022, 12:21am UTC](https://discourse.cmake.org/t/cmake-osx-sysroot-does-not-guide-compiler-selection/4872/4 "2022-02-14T00:21:45Z")
> [@JoeM](#):
>
> I know this only affects a small set of users doing development w/ CMake here but it’d be great to figure out a fix that could be upstreamed.
Does adding the flag work with more generally-available toolchains/SDKs? If so, that seems fine. Note that we support some pretty old Xcode versions (I think), so when that flag started becoming available would be of interest as well.
FYI @brad.king
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [February 14, 2022, 3:59pm UTC](https://discourse.cmake.org/t/cmake-osx-sysroot-does-not-guide-compiler-selection/4872/5 "2022-02-14T15:59:58Z")
See [CMake Issue 19180](https://gitlab.kitware.com/cmake/cmake/-/issues/19180) that proposes to remove the macOS compiler unwrapping altogether.
In the meantime, I’d be fine with a change to add `-sdk` to the unwrapping logic. The sysroot selection should be done before that already, IIRC.
---
### Author:  [@JoeM](https://discourse.cmake.org/u/JoeM)
#### Post date: [February 15, 2022, 5:57am UTC](https://discourse.cmake.org/t/cmake-osx-sysroot-does-not-guide-compiler-selection/4872/6 "2022-02-15T05:57:20Z")
> [@ben.boeckel](#):
>
> Does adding the flag work with more generally-available toolchains/SDKs?
Yes, the behavior for existing, public SDKs should be unchanged.
I’ll look into opening a PR. Thanks!
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [October 29, 2024, 5:08am UTC](https://discourse.cmake.org/t/cmake-osx-sysroot-does-not-guide-compiler-selection/4872/7 "2024-10-29T05:08:20Z")
> [@JoeM](#):
>
> Xcode follows the SDK settings to find the compiler from the linked toolchain.
So it would be possible to use **Xcode** with _clang-19_?