Bindgen can't find stddef.h

[jdm]

From servo/servo#19129 (comment):

error: failed to run custom build command for `gecko-media v0.1.0 (https://github.com/servo/gecko-media.git#0299b455)`
process didn't exit successfully: `/home/anholt/src/servo/servo/target/release/build/gecko-media-59486aef098dd7b4/build-script-build` (exit code: 101)

[...]

--- stderr
gecko/glue/include/GeckoMedia.h:10:10: fatal error: 'stddef.h' file not found
gecko/glue/include/GeckoMedia.h:10:10: fatal error: 'stddef.h' file not found, err: true
thread 'main' panicked at 'Unable to generate bindings: ()', /checkout/src/libcore/result.rs:906:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Any suggestions?

[jdm]

(This is a linux builder)

[ferjm]

Is this on Ubuntu? IIRC bindgen uses clang, so could it be https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1242300 ?

[MortimerGoro]

I have Ubuntu 16.04, and had this problem just running bindgen from CLI to manually generate some bindings. I think that it dependes on both the bindgen version and installed clang version: I have the problem on my desktop but not on the laptop (both 16.04)

I have not tried yet to build the latest Servo.

[anholt]

I'm on debian unstable. I see lots of the referenced types of symlinks from that bug report that do point to directories containing stddef.h. This will probably need a giant strace to figure out what's missing.

[jonleighton]

I have encountered this problem too, on Fedora.

[BruceDai]

I tried to install clang on my PC on Ubuntu 16.04.3 LTS with Intel CPU, my reported #19300 was fixed, and I can build servo successfully. I'm not sure whether my solution works for this issue.

[jonleighton]

I ran with strace -f, here is the relevant output:

[pid  9764] open("/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/stddef.h", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  9764] open("/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/x86_64-redhat-linux/stddef.h", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  9764] open("/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/backward/stddef.h", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  9764] open("/usr/local/include/stddef.h", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  9764] open("/usr/include/stddef.h", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  9764] open("gecko/glue/include/stddef.h", O_RDONLY) = -1 ENOENT (No such file or directory)

The file is located at /usr/lib/gcc/x86_64-redhat-linux/7/include/stddef.h on my system.

I've no idea how to make it work, but perhaps this info helps...

[jonleighton]

Ok, finally I have been able to solve this on my system. The solution is embarrassing: when @BruceDai reported that he solved it by installing clang, I got confused between clang and cmake. I ended up verifying that cmake was installed, and then concluding that his solution didn't work for me.

So anyway, I have some more details. On Fedora, there is a clang-libs package, and a separate clang package. I had clang-libs installed but not clang. clang-libs provides, AFAICT, libclang. libclang is used by bindgen (via clang-sys) to parse the header files in order to generate the bindings. When libclang is invoked, it ends up looking for stddef.h, but fails to find it. On Fedora, the clang package contains the file /usr/lib64/clang/4.0.1/include/stddef.h, and once the clang package is installed, libclang is able to find the file.

I feel like somewhere along this chain, something should be shouting louder about the problem/solution, but I'm not exactly sure where that responsibility lies. Maybe in clang-sys? (cc @KyleMayes in case you have input on this.)

[anholt]

Similarly, I had libclang-3.9 on debian, but not clang itself.

[vks]

Also see rsmpi/rsmpi#1 (comment) for possibly fixing this issue by adding some pathes to C_INCLUDE_PATH.