Compiling on Windows: 'stdbool.h' file not found

[Trayani]

Hi all, I have installed Rust and LLVM binaries with LIBCLANG_PATH pointing to LLVM's bin folder (I had this issue, initially).

Now, when I run cargo build, the build fails with

$ cargo build
Compiling gdnative-sys v0.5.0 (...\gdnative-sys)
error: failed to run custom build command for gdnative-sys v0.5.0 (...\godot-rust\gdnative-sys)

Caused by:
  process didn't exit successfully: ...\godot-rust\target\debug\build\gdnative-sys-5d7476379ddb4a91\build-script-build (exit code: 101)
--- stderr

...\godot-rust\gdnative-sys/godot_headers\gdnative/gdnative.h:62:10: fatal error: 'stdbool.h' file not found
...\godot-rust\gdnative-sys/godot_headers\gdnative/gdnative.h:62:10: fatal error: 'stdbool.h' file not found, err: true
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.

I googled a potential solution, but did not find it - it is being suggested to install clang for Linux users which is hardly possible with Windows (LLVM binaries should be enough, as far as I know).

[Trayani]

Adding the backtrace:

stack backtrace:
   0: backtrace::backtrace::dbghelp::trace
             at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc629                                                                                                                                                                                               9db9ec823\backtrace-0.3.34\src\backtrace/dbghelp.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc629                                                                                                                                                                                               9db9ec823\backtrace-0.3.34\src\backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src\libstd\sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src\libstd\sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src\libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src\libstd/panicking.rs:214
   6: std::panicking::rust_panic_with_hook
             at src\libstd/panicking.rs:477
   7: std::panicking::continue_panic_fmt
             at src\libstd/panicking.rs:384
   8: rust_begin_unwind
             at src\libstd/panicking.rs:311
   9: core::panicking::panic_fmt
             at src\libcore/panicking.rs:85
  10: core::result::unwrap_failed
             at src\libcore/result.rs:1084
  11: core::result::Result<T,E>::expect
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\src\libcore/resu                                                                                                                                                                                               lt.rs:879
  12: build_script_build::header_binding::generate
             at .\build.rs:69
  13: build_script_build::main
             at .\build.rs:7
  14: std::rt::lang_start::{{closure}}
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\src\libstd/rt.rs                                                                                                                                                                                               :64
  15: std::rt::lang_start_internal::{{closure}}
             at src\libstd/rt.rs:49
  16: std::panicking::try::do_call
             at src\libstd/panicking.rs:296
  17: __rust_maybe_catch_panic
             at src\libpanic_unwind/lib.rs:80
  18: std::panicking::try
             at src\libstd/panicking.rs:275
  19: std::panic::catch_unwind
             at src\libstd/panic.rs:394
  20: std::rt::lang_start_internal
             at src\libstd/rt.rs:48
  21: std::rt::lang_start
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\src\libstd/rt.rs                                                                                                                                                                                               :64
  22: main
  23: _tmainCRTStartup
  24: mainCRTStartup
  25: unit_addrs_search
  26: unit_addrs_search

[ghost]

Do you have the latest Visual Studio installed? I think Clang on Windows still uses MSVC headers by default. A google search indicated that stdbool.h is part of the C99 standard which was not supported by earlier versions of MSVC.

If you do have the latest VS, did you try building from the "developer console", available as a shortcut in the start menu? It sets many environment variables that may not be present in an ordinary cmd.

---

Actually, I think only the build tools should be required: https://aka.ms/buildtools

[ghost]

I'm able to build the library from scratch normally with Visual Studio Community 2019 installed.

[Trayani]

Thank you for the reply. I do have MSVC 2019 with the build tools installed (also various other extensions that could have helped based on their name). Unfortunately, I get the same result even when I run the build from MSVC's command line =(. I even tried to reinstall MSVC and run the command from MINGW and basic cmd.

I understand that the latest MSVC should have proper support now. My issue seems a bit unordinary (based on my research). I may select c++ standards 14, 17 and "latest". I wonder if there is a way to check, that the MSVC is recognized during compiling.

[ghost]

Well, in that case I don't think much can be done here at godot-rust, since this is most likely a problem with your specific environment.

If you think this might have been a problem with bindgen (not finding your standard headers), please report the issue to their repository.

[Trayani]

I found a workaround. I installed clang and rust via MSYS2 and successfully finished compilation with it.

For anyone with the same issue, here are the links to follow: http://blog.johannesmp.com/2015/09/01/installing-clang-on-windows-pt3/ https://users.rust-lang.org/t/how-do-i-use-msys2/18928 Also note, that you will still need LLVM binaries installed with LIBCLANG_PATH set to the bin folder.

[bluenote10]

I had the same problem, but on Ubuntu 18.04. Apparently installing only libclang-6.0-dev is not sufficient (as suggested by the blog post). I solved the problem by installing clang-6.0 and llvm as well.