Cross-compiled crate appears to include host header files after 0.30

[thenewwazoo]

When building bindings for an embedded OS, updating the dependency from 0.30 to 0.31 causes an error when Builder::generate is called. To repro (this assumes you've got arm-none-eabi tools installed):

$ git clone --recursive git@github.com:thenewwazoo/ChibiOS-rust.git && cd ChibiOS-rust
$ rustup override set nightly
$ cp -R os_ports/* ChibiOS/
$ xargo build --target thumbv7m-none-eabi --features stm32f407xg

The crate will build successfully.

Updating bindgen to 0.31 results in the following output:

<successful output snipped>
--- stderr
/usr/include/sys/cdefs.h:761:2: error: Unsupported architecture
/usr/include/machine/_types.h:34:2: error: architecture not supported
/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'
/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t'
/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t'
/usr/include/sys/_types.h:60:9: error: unknown type name '__uint32_t'
/usr/include/sys/_types.h:61:9: error: unknown type name '__uint32_t'
/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t'
/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t'
/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t'
/usr/include/sys/_types.h:71:9: error: unknown type name '__int64_t'
/usr/include/sys/_types.h:72:9: error: unknown type name '__int32_t'
/usr/include/sys/_types.h:73:9: error: unknown type name '__uint32_t'
/usr/include/sys/_types.h:74:9: error: unknown type name '__int32_t'
/usr/include/sys/_types.h:75:9: error: unknown type name '__uint32_t'
/usr/include/sys/_types.h:76:9: error: unknown type name '__uint32_t'
/usr/include/machine/types.h:37:2: error: architecture not supported
/usr/include/sys/_types/_intptr_t.h:32:9: error: unknown type name '__darwin_intptr_t'
/usr/include/sys/cdefs.h:761:2: error: Unsupported architecture, err: true
/usr/include/machine/_types.h:34:2: error: architecture not supported, err: true
/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t', err: true
/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t', err: true
/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t', err: true
/usr/include/sys/_types.h:60:9: error: unknown type name '__uint32_t', err: true
/usr/include/sys/_types.h:61:9: error: unknown type name '__uint32_t', err: true
/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t', err: true
/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t', err: true
/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t', err: true
/usr/include/sys/_types.h:71:9: error: unknown type name '__int64_t', err: true
/usr/include/sys/_types.h:72:9: error: unknown type name '__int32_t', err: true
/usr/include/sys/_types.h:73:9: error: unknown type name '__uint32_t', err: true
/usr/include/sys/_types.h:74:9: error: unknown type name '__int32_t', err: true
/usr/include/sys/_types.h:75:9: error: unknown type name '__uint32_t', err: true
/usr/include/sys/_types.h:76:9: error: unknown type name '__uint32_t', err: true
/usr/include/machine/types.h:37:2: error: architecture not supported, err: true
/usr/include/sys/_types/_intptr_t.h:32:9: error: unknown type name '__darwin_intptr_t', err: true
thread 'main' panicked at 'unable to generate cmsis bindings: ()', libcore/result.rs:916:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

(looking at the backtrace points to where I expect the generate call)

Relevant host information:

Darwin hartwell.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov  9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848]
Apple LLVM version 9.0.0 (clang-900.0.39.2)
rustc 1.25.0-nightly (e6072a7b3 2018-01-13)

You can find the __bindgen.i file here

[thenewwazoo]

I added a "successful" dump to the gist (they're named __bindgen.i (0.3?))

[fitzgen]

Thanks for the bug report!

The best way to help solve it would be to create a minimal, standalone test case that reproduces system headers getting included. Unfortunately, because this has to do with includes and include paths, I don't think creduce will be of much use here.

[trlim]

I've been experiencing similar problem.

For simple wrapper.h containing:

#include <stdint.h>

Running cargo build --target=arm-unknown-linux-gnueabi with build.rs

let bindings = bindgen::Builder::default()
    .header("wrapper.h")
    .generate()
    .expect("Unable to generate bindings");

or running the following command

$ TARGET=arm-unknown-linux-gnueabi bindgen wrapper.h

produces the same error.

/usr/include/x86_64-linux-gnu/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found
/usr/include/x86_64-linux-gnu/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found, err: true
thread 'main' panicked at 'Unable to generate bindings: ()', /checkout/src/libcore/result.rs:916:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I had to add explicit --sysroot clang argument when I cross compile for ARM target.

.clang_arg("--sysroot=/my/path/to/arm/sysroot")

[jdonald]

I encountered the same problem where the i386 stubs-32.h was getting referenced when trying to cross-compile for armhf. I was able to get past it by modifying build_gecko.rs with something similar to @trlim's suggestion:

            let mut builder = Builder::default()
+               .clang_arg("-target")
+               .clang_arg("arm-linux-gnueabihf")
                .rustfmt_bindings(false)
                .rust_target(RustTarget::Stable_1_0);

That was on Xenial, then on Bionic it still couldn't find the proper cross-target headers, and complained about being unable to find <bits/c++config.h>, so with another hint from Stack Overflow I ended up using:

            let mut builder = Builder::default()
+               .clang_arg("-target")
+               .clang_arg("arm-linux-gnueabihf")
+               .clang_arg("-I/usr/arm-linux-gnueabihf/include/c++/7")
+               .clang_arg("-I/usr/arm-linux-gnueabihf/include/c++/7/arm-linux-gnueabihf")
                .rustfmt_bindings(false)
                .rust_target(RustTarget::Stable_1_0);

and then was able to cross-compile all the Rust code in Firefox 59.

[jhwgh1968]

Hey everyone, I've added the ability to pass additional clang arguments through an environment variable, while trying trying to tackle this exact problem. If you use that to pass --sysroot /path/to/cross/dir to clang, it should fix these issues.

If anyone could try that, perhaps this bug could be closed.

[mdavidsaver]

With bindgen 0.55.1 I am able to cross-compile (host debian 10, target raspbian 10) for a raspberry pi zero w with:

$ cat .cargo/config 
[target.arm-unknown-linux-gnueabi]
linker = "arm-linux-gnueabi-gcc"
$ BINDGEN_EXTRA_CLANG_ARGS='--sysroot /usr/arm-linux-gnueabi' cargo build --target arm-unknown-linux-gnueabi

It would be convenient if the sysroot directory could be specified alongside the linker in a cargo config file.

[jhwgh1968]

It would be convenient if the sysroot directory could be specified alongside the linker in a cargo config file.

Even if the crate were to read an extra parameter from .cargo/config (which is probably not supported by cargo directly, and would be working around it), I suspect it would be difficult to provide in a truly agnostic way.

There are a number of behavior changes between gcc versions and linkers. Since a lot of cross compiling involves 3rd party or vendor toolchains, I don't know that any single set of parameters would be portable.

For the case I was working on when I wrote this, I also found that I needed more than just a sysroot. Looking at how bindgen propagated arguments prior to that, I thought "extra clang args" was the best solution.