RustAudio / coreaudio-sys

Raw bindings to the OSX CoreAudio framework generated by bindgen (see coreaudio-rs for a more rust-esque wrapper).
MIT License
67 stars 38 forks source link

Build error on macOS 10.12 #25

Open jgouly opened 5 years ago

jgouly commented 5 years ago
error: failed to run custom build command for `coreaudio-sys v0.2.2` process didn't exit successfully: `../debug/build/coreaudio-sys-0b03ecb47a91dd35/build-script-build` (exit code: 101)
--- stdout
cargo:rustc-link-lib=framework=AudioUnit
cargo:rustc-link-lib=framework=CoreAudio  

--- stderr
error: header '/System/Library/Frameworks/CoreAudio.framework/Headers/CoreAudio.h' does not exist.

The header is here:

$ find /Applications/Xcode.app/Contents/Developer -name CoreAudio.h

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreAudio.framework/Versions/A/Headers/CoreAudio.h

bbannier commented 5 years ago

I ran into the same issue. After digging deeper the issue for seemed to be that I had multiple clang versions installed (llvm package via homebrew, system clang). I was unsuccessful with seting LIBCLANG_PATH to the lib directory under the path pointed to by xcode-select -p (as suggested in the bindgen docs, https://github.com/rust-lang/rust-bindgen/blob/master/CONTRIBUTING.md#user-content-building), but overriding PATH did it for me.

PATH=/usr/bin:$PATH cargo build

I am pretty that there should way coreaudio-sys could avoid setting up an inconsistent bindgen Builder env.

blinsay commented 4 years ago

having the same problem on osx 10.14 with Command Line Tools but not XCode installed

   Compiling coreaudio-sys v0.2.0
error: failed to run custom build command for `coreaudio-sys v0.2.0`

Caused by:
  process didn't exit successfully: `/Users/benl/src/beepeeyou/target/debug/build/coreaudio-sys-c27e897519d4a870/build-script-build` (exit code: 101)
--- stdout
cargo:rustc-link-lib=framework=AudioUnit
cargo:rustc-link-lib=framework=CoreAudio

--- stderr
error: header '/System/Library/Frameworks/CoreAudio.framework/Headers/CoreAudio.h' does not exist.
thread 'main' panicked at 'unable to generate bindings: ()', src/libcore/result.rs:1084:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
$ xcode-select -p
/Library/Developer/CommandLineTools
$ find /Library/Developer/CommandLineTools -name CoreAudio.h
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreAudio.framework/Versions/A/Headers/CoreAudio.h
danwilhelm commented 3 years ago

I also experienced this on Mac 11.2.3 when updating command line tools/XCode.

You can verify the path the build script looks in: xcrun --sdk macosx --show-sdk-path. Mine returned: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk, which is a symlink to MacOSX.sdk.

At the time, I noticed one of these would not open in Finder (perhaps because I had two command line tools versions). That indicated that perhaps the symlink was not properly working.

One workaround that I found did work was defining the environment variable COREAUDIO_SDK_PATH, as mentioned in the README. That said, eventually when I rebooted my system the issue disappeared (perhaps upon reboot the symlink was updated?).

alisomay commented 2 years ago

The problem I had


Missing headers for IOS builds.

This bit of code used in build.rs to determine which SDK to use.

    let sdk = if target.contains("apple-darwin") {
        "macosx"
    } else if target == "x86_64-apple-ios" || target == "i386-apple-ios" {
        "iphonesimulator"
    } else if target == "aarch64-apple-ios"
        || target == "armv7-apple-ios"
        || target == "armv7s-apple-ios"
    {
        "iphoneos"
    } else {
        unreachable!();
    };

Then a command is run to determine where the SDK is

    let output = Command::new("xcrun")
        .args(&["--sdk", sdk, "--show-sdk-path"])
        .output()?
        .stdout;

The command run in the upper snippet is xcrun --sdk "name-of-the-sdk" --show-sdk-path

It errors when it does not find the SDK which is searched for.

ex.

xcodebuild: error: SDK "name-of-the-sdk" cannot be located.
xcodebuild: error: SDK "name-of-the-sdk" cannot be located.
xcrun: error: unable to lookup item 'Path' in SDK 'name-of-the-sdk'

which will result that the output variable become an empty string. Because it only captures stdout. This will result with the build failing.

The solution


SDKs for iphoneos and iphonesimulator are not included by default when you install Xcode Command Line Tools. Unfortunately a full version of Xcode should be installed to have them available. Installing the full version of Xcode will fix this issue. If you have the same issue as me.

frederickjjoubert commented 10 months ago

I'm working on a Rust + Bevy project and I ran into this problem.

The following solution worked for me:

cargo update
cargo clean
rm -rf target Cargo.lock
cargo build