为什么 gcc 从不存在的文件夹中搜索头文件？
Why does gcc search header files from non-exist folders?
我正在尝试在 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 是怎么来的。谁能给点线索？
I can't work out how /usr/lib/gcc/x86_64-linux-gnu/4.8 and /usr/include/x86_64-linux-gnu come from.
这些头文件随 gcc 安装。它们是 OS 头文件的副本，已修补以使用 gcc 进行干净编译。一些本机 OS 头文件（例如在 Solaris、BSD 上）不能用 gcc 干净地编译。
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdarg.h',needed by core/luv/luv.o'.
上面说 luv.o 是在 /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdarg.h 存在时构建的。可能是您在另一台机器上构建了 .o 文件。删除所有 .o 和 .d 文件或尝试 make clean.
作者已将特定于他的系统的文件上传到源存储库（参见 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）对我有用。
我正在尝试在 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 是怎么来的。谁能给点线索？
I can't work out how
/usr/lib/gcc/x86_64-linux-gnu/4.8and/usr/include/x86_64-linux-gnucome from.
这些头文件随 gcc 安装。它们是 OS 头文件的副本，已修补以使用 gcc 进行干净编译。一些本机 OS 头文件（例如在 Solaris、BSD 上）不能用 gcc 干净地编译。
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdarg.h',needed bycore/luv/luv.o'.
上面说 luv.o 是在 /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdarg.h 存在时构建的。可能是您在另一台机器上构建了 .o 文件。删除所有 .o 和 .d 文件或尝试 make clean.
作者已将特定于他的系统的文件上传到源存储库（参见 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）对我有用。