Regression in 1.1.32 - unable to build on mac m1

[dignifiedquire]

Starting with 1.1.32 I am unable to build ring on my machine. Downgrading to 1.1.31 fixes the issue.
Rust version both 1.82 stable and nightlies reproduce the error for me.

Also other crates fail to build for me, eg blake3 fails with missing assert.h

System:

• mac m1
• xcode 16.1
• macos 15.1

Some more error details can be found in briansmith/ring#1942

Error output:

--- stdout
  cargo:rerun-if-env-changed=RING_PREGENERATE_ASM
  cargo:rustc-env=RING_CORE_PREFIX=ring_core_0_17_8_
  OPT_LEVEL = Some(0)
  OUT_DIR = Some(/Users/dignifiedquire/rust_target/debug/build/ring-2479b8f424b81183/out)
  TARGET = Some(aarch64-apple-darwin)
  HOST = Some(aarch64-apple-darwin)
  cargo:rerun-if-env-changed=CC_aarch64-apple-darwin
  CC_aarch64-apple-darwin = None
  cargo:rerun-if-env-changed=CC_aarch64_apple_darwin
  CC_aarch64_apple_darwin = None
  cargo:rerun-if-env-changed=HOST_CC
  HOST_CC = None
  cargo:rerun-if-env-changed=CC
  CC = Some(clang)
  cargo:rerun-if-env-changed=CC_KNOWN_WRAPPER_CUSTOM
  CC_KNOWN_WRAPPER_CUSTOM = None
  RUSTC_WRAPPER = None
  cargo:rerun-if-env-changed=CC_ENABLE_DEBUG_OUTPUT
  cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some(true)
  cargo:rerun-if-env-changed=MACOSX_DEPLOYMENT_TARGET
  MACOSX_DEPLOYMENT_TARGET = None
  cargo:rerun-if-env-changed=CFLAGS_aarch64-apple-darwin
  CFLAGS_aarch64-apple-darwin = None
  cargo:rerun-if-env-changed=CFLAGS_aarch64_apple_darwin
  CFLAGS_aarch64_apple_darwin = None
  cargo:rerun-if-env-changed=HOST_CFLAGS
  HOST_CFLAGS = None
  cargo:rerun-if-env-changed=CFLAGS
  CFLAGS = None
  cargo:warning=In file included from crypto/curve25519/curve25519.c:22:
  cargo:warning=In file included from include/ring-core/mem.h:60:
  cargo:warning=include/ring-core/base.h:71:10: fatal error: 'TargetConditionals.h' file not found
  cargo:warning=   71 | #include <TargetConditionals.h>
  cargo:warning=      |          ^~~~~~~~~~~~~~~~~~~~~~
  cargo:warning=1 error generated.

  --- stderr


  error occurred: Command env -u IPHONEOS_DEPLOYMENT_TARGET "clang" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-2" "-fno-omit-frame-pointer" "--target=arm64-apple-macosx15.1" "-mmacosx-version-min=15.1" "-I" "include" "-I" "/Users/dignifiedquire/rust_target/debug/build/ring-2479b8f424b81183/out" "-Wall" "-Wextra" "-fvisibility=hidden" "-std=c1x" "-Wall" "-Wbad-function-cast" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wnested-externs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wstrict-prototypes" "-Wundef" "-Wuninitialized" "-gfull" "-DNDEBUG" "-o" "/Users/dignifiedquire/rust_target/debug/build/ring-2479b8f424b81183/out/fad98b632b8ce3cc-curve25519.o" "-c" "crypto/curve25519/curve25519.c" with args clang did not execute successfully (status code exit status: 1).

[NobodyXu]

cc @madsmtm I guess this is probably due to passing apple minimum os in target?

[madsmtm]

I guess this is probably due to passing apple minimum os in target?

I can't see how that would make TargetConditionals.h non-existent? Rather, I think the issue is that the clang binaries that people are using is not the trampoline in /usr/bin/clang (see rust-lang/rust#131477 for some details on that), which means that SDKROOT isn't set automatically?

I.e. I think that the workaround done below is wrong, and we should just always pass SDKROOT:

cc-rs/src/lib.rs

Line 2544 in 2050013

if cmd.is_xctoolchain_clang() || target.os != "macos" {

That said, still don't understand why people's builds weren't broken before this? Don't have the time rn, but will try to take a closer look soon.

[dignifiedquire]

If it helps on my machine I have

• clang: /opt/homebrew/opt/llvm/bin/clang
• export CPATH="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include,/Library/Developer/CommandLineTools/usr/include/c++/v1,$CPATH"

to make things work

[dignifiedquire]

The headers like TargetConditionals.h live in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include

[madsmtm]

So, the change to the commandline options that we pass between 1.1.31 and 1.1.32 is that instead of passing --target=arm64-apple-darwin, we now pass --target=arm64-apple-macosx15.0.

I wonder if homebrew's Clang has special handling for the -darwin target?

[madsmtm]

Ah, indeed it does! Homebrew installs a config file for *-apple-darwin, but not for *-apple-macosx:

https://github.com/Homebrew/homebrew-core/blob/f8b6e58cbe7b244511167ecc13f8c2992d8b50a7/Formula/l/llvm.rb#L499-L513

[madsmtm]

Hmm, though that's only since Homebrew/homebrew-core#196094, which was merged a week ago.

Which version of Homebrew do you have?

[madsmtm]

I've tried to fix this in https://github.com/madsmtm/homebrew-core/tree/clang-macosx, but am unsure at this point that that's the correct way forwards.

In any case, I feel like this is really a Homebrew issue (and the method that they're using feels brittle for many reasons).

[madsmtm]

Opened Homebrew/homebrew-core#197278

[carlocab]

I tried to skim #1252, but I couldn't find the answer. Is there any reason why you don't want to use *-apple-darwin in the target triple? It's what Apple Clang uses:

❯ xcrun clang --print-target-triple
arm64-apple-darwin24.1.0
❯ xcrun -sdk macosx15.1 clang --print-target-triple
arm64-apple-darwin24.1.0

[madsmtm]

I tried to skim #1252, but I couldn't find the answer. Is there any reason why you don't want to use *-apple-darwin in the target triple?

Because semantically, it makes it very clear to Clang that the target is macOS, and not one of the other Darwin platforms. If you use echo > foo.c && xcrun -sdk macosx15.1 clang -v foo.c, you'll see that the actual triple that Clang resolved to passing to the compiler backend is arm64-apple-macosx15.1.0.
The *-apple-darwin triple seems mostly like a (backwards compatibility?) hack to support overriding the triple by providing a different SDK root (the triple changes to arm64-apple-ios18.0.0 if you run with xcrun -sdk iphoneos clang -v foo.c).

And because practically, it's easier to exactly specify the macOS deployment target that way (otherwise we need to maintain a mapping from macOS to Darwin versions). (Though I guess we could set MACOSX_DEPLOYMENT_TARGET / -mmacosx-version-min= / -mtargetos=, and let Clang sort it out).

[carlocab]

otherwise we need to maintain a mapping from macOS to Darwin versions

Having such a mapping isn't that bad: https://github.com/Homebrew/brew/blob/40f4ab25468bce1640b5ec7ff34fed271cad6e4f/Library/Homebrew/macos_version.rb#L34-L43

[richarddd]

Any updates on this?

[NobodyXu]

I think @madsmtm is working with upstream (homebrew/llvm) to fix this