gcc包括命令壞了？

Question

我遇到了奇怪的問題，即linux C++編譯器包含本地目錄中的文件而不是系統目錄。使用（-H）選項查看預編譯器輸出。由此可以看出，系統文件/usr/include/sched.h忽然包括從本地目錄time.h中頭，而不是系統中的一個。我認爲，如果包括文件內<>括號系統目錄應先擡頭，

從sched.h中相關線上： -

#include <time.h> 

編譯器輸出， （-H）選項： -

..... /usr/include/c++/4.6/bits/basic_string.h 
...... /usr/include/c++/4.6/ext/atomicity.h 
....... /usr/include/c++/4.6/i686-linux-gnu/./bits/gthr.h 
........ /usr/include/c++/4.6/i686-linux-gnu/./bits/gthr-default.h 
......... /usr/include/pthread.h 
.......... /usr/include/sched.h 
........... /usr/lib/gcc/i686-linux-gnu/4.6.1/include/stddef.h 
........... /home/borisu/ivrworx-lnx/src/iw_core/../kentcsp/src/time.h <<<< WHY ??? 

編譯器目錄海RCH

$ gcc -xc++ -E -v - 
Using built-in specs. 
COLLECT_GCC=gcc 
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6.1/lto-wrapper 
Target: i686-linux-gnu 
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu 
Thread model: posix 
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=i686' 
/usr/lib/gcc/i686-linux-gnu/4.6.1/cc1plus -E -quiet -v -imultilib . -imultiarch i386-linux-gnu -D_GNU_SOURCE - -mtune=generic -march=i686 -fstack-protector 
ignoring nonexistent directory "/usr/local/include/i386-linux-gnu" 
ignoring nonexistent directory "/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../i686-linux-gnu/include" 
#include "..." search starts here: 
#include <...> search starts here: 
/usr/include/c++/4.6 
/usr/include/c++/4.6/i686-linux-gnu/. 
/usr/include/c++/4.6/backward 
/usr/lib/gcc/i686-linux-gnu/4.6.1/include 
/usr/local/include 
/usr/lib/gcc/i686-linux-gnu/4.6.1/include-fixed 
/usr/include/i386-linux-gnu 
/usr/include 
End of search list. 

文件存在：

$ ll /usr/include/time.h 
-rw-r--r-- 1 root root 13534 2012-03-07 04:47 /usr/include/time.h 

Answer 1

我想如果include文件內<>括號系統目錄應先擡頭，

你認爲不正確。引用gcc手冊頁：

在標準系統包含目錄之前搜索由-I命名的目錄。

你可能在你的gcc命令行中指定了-I../kentcsp/src。

考慮使用-iquote或-idirafter指令。

Answer 2

通用的規則，這似乎是有效的大多數，如果不是全部 編譯器，是在目錄當中 #include "..."首先查找包含與包含，然後procedes作爲#include <...>文件。任何-I（或'/ I'for Windows）選項都會影響包含這兩種形式的 。由於這個原因，包含在一個項目中（即使那個項目是「系統標題」）通常會使用"..."表格，而 是一個完整的相對路徑，這樣就不會有任何項目被外部接收到的任何東西 。初看來，它看起來像g ++已經取代 stddef.h（所以你得到它的版本，而不是在/usr/include）， 但不是time.h;由於包含stddef.h將不會在 目錄中找到time.h它所在的目錄，因此它會回落到由-I, 指定的列表，然後是由編譯器添加的一些隱式路徑。我會考慮 這是一個錯誤。

錯誤與否，使用標題與標準標題相同的名稱是不是 一個好主意。如果讀者看到包含time.h，而不管 包含哪種類型，他將立即假定系統標題。 更改包含文件的名稱。

Answer 3

一直有類似的問題 - 事實證明，gcc玩頭文件遊戲。一個很好的解釋可在http://ewontfix.com/12/