-
Notifications
You must be signed in to change notification settings - Fork 696
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
"fatal error: 'string' file not found" on macOS #1834
Comments
Repro here https://github.com/LoganDark/bindgen-hates-macos if anyone has a macOS 10.14 machine. |
I easily reproduced this on my macOS 10.14.6 machine. cd $(mktemp -d)
git clone https://github.com/LoganDark/bindgen-hates-macos.git
cargo test I do not know anything further at this time. I might be able to look at this on Friday. |
Yesss, thank you! |
Hey, any progress on this? Still impacted by this issue. |
I looked at this a little while longer. I agree that this particular problem should not arise (#1597 implies that I was able to work around the issue for your particular testcase by adding these two lines before .clang_arg("-I/Library/Developer/CommandLineTools/usr/include/c++/v1")
.clang_arg("-I/Library/Developer/CommandLineTools/usr/lib/clang/10.0.1/include") (the first arg for I understand that this is not really a solution, but I have no experience using |
Well, It is too a solution, but one I shouldn't have to apply myself. |
So it seems like the solution is specifying This could probably be fixed by |
similar problem on nixos linux let cppbindings = bindgen::Builder::default()
.header("src/ExportResult.hpp")
.whitelist_type("ExportResult")
.generate_comments(true)
.derive_default(true)
// Tell bindgen we are processing c++
.clang_arg("-xc++")
.clang_arg("-std=c++11")
// NixOS workaround to find header files
// https://github.com/rust-lang/rust-bindgen/issues/1834
// c2rust/c2rust-ast-exporter/src/ExportResult.hpp:11:10: fatal error: 'algorithm' file not found
.clang_arg(format!("-I{}/c++/v1", env::var("LIBCXX_INCLUDE_DIR").unwrap()))
// /nix/store/fpnnmg22plmha1qsq1fvsjsar3ziz2k1-libcxx-7.1.0-dev/include/c++/v1/__config:206:12: fatal error: 'features.h' file not found
.clang_arg(format!("-I{}", env::var("GLIBC_INCLUDE_DIR").unwrap()))
// /nix/store/fpnnmg22plmha1qsq1fvsjsar3ziz2k1-libcxx-7.1.0-dev/include/c++/v1/cstddef:44:15: fatal error: 'stddef.h' file not found
.clang_arg(format!("-I{}", env::var("LIBC_INCLUDE_DIR").unwrap()))
.generate()
.or(Err("Unable to generate ExportResult bindings"))?; # default.nix
{
preBuild = ''
export LIBCLANG_PATH=${pkgs.libclang.lib}/lib
export LIBCXX_INCLUDE_DIR=${pkgs.libcxx.dev}/include
export GLIBC_INCLUDE_DIR=${pkgs.glibc.dev}/include
export LIBC_INCLUDE_DIR=${pkgs.libclang.lib}/lib/clang/7.1.0/include
''; |
This PR replaces an unmaintained fork of secp256k1 to the latest version of the original library that already have all required features with a more clear API. Also this will solve compilation issues with llvm 13.* tools on MacOS like the next: rust-lang/rust-bindgen#1834
This PR replaces an unmaintained fork of secp256k1 to the latest version of the original library that already have all required features with a more clear API. Also this will solve compilation issues with llvm 13.* tools on MacOS like the next: rust-lang/rust-bindgen#1834
This PR replaces an unmaintained fork of secp256k1 to the latest version of the original library that already have all required features with a more clear API. Also this will solve compilation issues with llvm 13.* tools on MacOS like the next: rust-lang/rust-bindgen#1834
I hit this on Linux (Ubuntu) as well. I ended up manually adding:
to my |
I hit this on macos after a system update seems to have broken my non-app-store-installed copy of xcode. I realized I could work around it by setting |
@spacejam Thank you so much for sharing. Solved my issue. |
Input C/C++ Header
Bindgen Invocation
Actual Results
Expected Results
I expected no fatal error.
This has happened on every single
clang
on my macOS 10.14.6 system, even if I try to specify include paths and stuff. Also it's really weird. Look here:Maybe the compiler's wrong? Nope.
Let's try letting bindgen find the default Apple compiler:
Nope. Surely it must not work right?
It does. However, with all the extra flags added by
bindgen
it doesn't:So telling bindgen not to add those flags should work then, right?
Nope...
The text was updated successfully, but these errors were encountered: