Open LoganDark opened 4 years ago
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 #include <string>
works on non-macOS platforms).
I was able to work around the issue for your particular testcase by adding these two lines before .generate()
:
.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 <string>
and the second for <stdarg.h>
).
I understand that this is not really a solution, but I have no experience using bindgen
with C++, so I am not likely to be much more help myself. Perhaps @emilio has seen something like this before.
Well, bindgen
already tries to detect include paths so I suppose it should know this already.
It is too a solution, but one I shouldn't have to apply myself. bindgen
should understand that these options are necessary (in that order too) and automatically apply them. Either that, or it should invoke the compiler in such a way that these options are not necessary to explicitly provide (maybe not possible with libclang, I'm not sure).
So it seems like the solution is specifying /Library/Developer/CommandLineTools/usr/include/c++/v1
before the other include paths - since stuff uses #include_next
, the included file has to exist after that file in the include chain, not before. That's hilarious, because bindgen seems to just throw flags around carelessly.
This could probably be fixed by bindgen
automatically finding the STL and including it first in the include chain. That solution is cross-platform and could also be preventative towards other, unforeseen issues.
similar problem on nixos linux
i must set include paths for bindgen::Builder::default()
in c2rust-ast-exporter/build.rs
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
'';
I hit this on Linux (Ubuntu) as well. I ended up manually adding:
#[cfg(target_os = "linux")]
let bindings = bindings
.clang_arg(format!("-I/usr/include/c++/11"))
.clang_arg(format!("-I/usr/include/x86_64-linux-gnu/c++/11"));
to my build.rs
.
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 export CPPFLAGS="-I/Library/Developer/CommandLineTools/SDKs/MacOSX14.5.sdk/usr/include/c++/v1/"
(a directory that contains iostream
and string
etc... on my system), but then I seem to have fixed it without explicitly setting that env var by going into the xcode Settings GUI, going to the "Locations" tab, and even though Command Line Tools already listed Xcode 16, when I clicked its drop down (there was only one option for me) and I re-selected it, it asked me to authenticate, and then suddenly the system started working again. Before explicitly clicking this, xcode-select --print-path
printed out /Library/Developer/CommandLineTools
, but after this reconfiguration it printed out /Applications/Xcode.app/Contents/Developer
, and then compilation started working as expected without the env var workaround. Hope this helps somebody!
@spacejam Thank you so much for sharing. Solved my issue.
Same issue as @spacejam, ran into similar errors after a macos system update. The brew-installed llvm was out of date. brew update && brew install llvm
fixed it for me (the brew-installed clang was my default)
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...