Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression in 1.1.32 - unable to build on mac m1 #1278

Open
dignifiedquire opened this issue Nov 7, 2024 · 12 comments
Open

Regression in 1.1.32 - unable to build on mac m1 #1278

dignifiedquire opened this issue Nov 7, 2024 · 12 comments

Comments

@dignifiedquire
Copy link

dignifiedquire commented Nov 7, 2024

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
Copy link
Collaborator

NobodyXu commented Nov 7, 2024

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

github-merge-queue bot pushed a commit to n0-computer/iroh that referenced this issue Nov 7, 2024
@madsmtm
Copy link
Contributor

madsmtm commented Nov 7, 2024

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
Copy link
Author

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
Copy link
Author

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

@madsmtm
Copy link
Contributor

madsmtm commented Nov 10, 2024

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
Copy link
Contributor

madsmtm commented Nov 10, 2024

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
Copy link
Contributor

madsmtm commented Nov 10, 2024

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

Which version of Homebrew do you have?

@madsmtm
Copy link
Contributor

madsmtm commented Nov 10, 2024

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
Copy link
Contributor

madsmtm commented Nov 11, 2024

Opened Homebrew/homebrew-core#197278

@carlocab
Copy link

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
Copy link
Contributor

madsmtm commented Nov 11, 2024

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants