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 ???

編譯器目錄搜索

$ 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

我假設如果包含文件在<>括號內，系統目錄應首先查找，

你假設不正確。 引用gcc手冊頁：

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

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

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

Answer 2

一般規則似乎對大多數（如果不是所有編譯器）都有效， #include "..."首先查看包含帶有include的文件的目錄，然后進行#include <...> 。 任何-I （或Windows的'/ I'）選項都會影響include的兩種形式。 出於這個原因，在項目中包含（即使該項目是“系統頭”）通常會使用"..."形式，具有完整的相對路徑，這樣就不會有任何外來的東西。項目。 在第一個視圖中，看起來g ++已經替換了stddef.h （所以你得到它的版本，而不是/usr/include ），而不是time.h ; 由於include stddef.h在它所在的目錄中找不到time.h ，它會回退到-I指定的列表，然后是編譯器添加的一些隱式路徑。 我認為這是一個錯誤。

是否存在錯誤，使用與標准標題同名的標題不是一個好主意。 如果讀者看到time.h的包含，無論包含哪種類型，他都會立即采用系統頭。 更改包含文件的名稱。

Answer 3

一直有類似的問題 - 事實證明，gcc使用頭文件玩游戲。 http://ewontfix.com/12/上提供了一個很好的解釋