Open jdm opened 6 years ago
(This is a linux builder)
Is this on Ubuntu? IIRC bindgen uses clang, so could it be https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1242300 ?
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.
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.
I have encountered this problem too, on Fedora.
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.
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...
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.)
Similarly, I had libclang-3.9 on debian, but not clang itself.
Also see https://github.com/bsteinb/rsmpi/issues/1#issuecomment-288521215 for possibly fixing this issue by adding some pathes to C_INCLUDE_PATH
.
From https://github.com/servo/servo/pull/19129#issuecomment-344495206:
Any suggestions?