为什么 gcc 从不存在的文件夹中搜索头文件？

Question

我正在尝试在CentOS 7 上构建一个开源项目shark，并得到非常奇怪的构建错误：

make: *** No rule to make target `/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdarg.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stddef.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed/limits.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed/syslimits.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/include/x86_64-linux-gnu/sys/cdefs.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/include/x86_64-linux-gnu/bits/wordsize.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/include/x86_64-linux-gnu/gnu/stubs.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/include/x86_64-linux-gnu/gnu/stubs-64.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/include/x86_64-linux-gnu/bits/posix1_lim.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/include/x86_64-linux-gnu/bits/local_lim.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/include/x86_64-linux-gnu/bits/posix2_lim.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/include/x86_64-linux-gnu/bits/types.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/include/x86_64-linux-gnu/bits/typesizes.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/include/x86_64-linux-gnu/bits/stdio_lim.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/include/x86_64-linux-gnu/bits/sys_errlist.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/include/x86_64-linux-gnu/bits/errno.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/include/x86_64-linux-gnu/asm/errno.h', needed by `core/luv/luv.o'.
make: *** No rule to make target `/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdint.h', needed by `core/luv/luv.o'.

执行“gcc -E -v -”命令后，输出：

[root@centos shark]# gcc -E -v -
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.8.3/cc1 -E -quiet -v - -mtune=generic -march=x86-64
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.8.3/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/4.8.3/include
 /usr/local/include
 /usr/include
End of search list.

所以搜索头文件路径应该是：

 /usr/lib/gcc/x86_64-redhat-linux/4.8.3/include
 /usr/local/include
 /usr/include

我不知道/usr/lib/gcc/x86_64-linux-gnu/4.8 和/usr/include/x86_64-linux-gnu 是怎么来的。谁能提供一些线索？

Answer 1

作者已将特定于他的系统的文件上传到源存储库（请参阅this issue report）。

解决方法是通过简单的grep 来查找有问题的文件：

grep -R /usr/lib/gcc ./*

结果（来自干净的git clone）

./bpf/libbpf/bpf_load.d: /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stddef.h \
./bpf/libbpf/bpf_load.d: /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdarg.h \
./bpf/libbpf/bpf_load.d: /usr/include/elf.h /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdint.h \
./bpf/libbpf/bpf_load.d: /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdbool.h \
./bpf/libbpf/libbpf.d: /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stddef.h \
./bpf/libbpf/libbpf.d: /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdarg.h \
./bpf/libbpf/libbpf.d: /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdint.h /usr/include/stdint.h \
./bpf/bpf.lua:   local clang_cmd = string.format("clang -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/include -I%s -I%s/arch/x86/include -I%s/arch/x86/include/generated/uapi -I%s/arch/x86/include/generated  -I%s/include -I%s/arch/x86/include/uapi -I%s/arch/x86/include/generated/uapi -I%s/include/uapi -I%s/include/generated/uapi -include %s/include/linux/kconfig.h %s -D__KERNEL__ -Wno-unused-value -Wno-pointer-sign -O2 -emit-llvm -x c -c %s -o %s", bpfinc, linuxinc, linuxinc, linuxinc, linuxinc, linuxinc, linuxinc, linuxinc, linuxinc, linuxinc, bpf.cargs_extra, srcfile, objfile)
./core/luv/luv.d: core/luajit/src/lua.h /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdarg.h \
./core/luv/luv.d: /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stddef.h \
./core/luv/luv.d: /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed/limits.h \
./core/luv/luv.d: /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed/syslimits.h \
./core/luv/luv.d: /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdint.h /usr/include/stdint.h \
Binary file ./perf/libtraceevent.a matches
Binary file ./perf/libapikfs.a matches
Binary file ./perf/libperf.a matches

删除有问题的 .d 文件（./bpf/libbpf/bpf_load.d、./bpf/libbpf/libbpf.d 和 ./core/luv/luv.d）对我有用。

Answer 2

我不知道/usr/lib/gcc/x86_64-linux-gnu/4.8 和/usr/include/x86_64-linux-gnu 是怎么来的。

这些头文件随 gcc 一起安装。它们是 OS 头文件的副本，已修补以使用 gcc 进行干净编译。一些本机 OS 头文件（例如，在 Solaris、BSD 上）不能用 gcc 干净地编译。

---

/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdarg.h',core/luv/luv.o' 需要。

上面说luv.o 是在/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdarg.h 存在时构建的。可能是您在另一台机器上构建了 .o 文件。删除所有.o 和.d 文件或尝试make clean。