我遇到了一个奇怪的问题，linux c++编译器包含来自本地目录而不是系统目录的文件。请参阅带有（-H）选项的预编译器输出。可以看出，系统文件/usr/include/sched.h突然包括来自本地目录的time.h头，而不是系统文件。我假设如果include文件在<>括号中的系统目录应该首先查找，
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
我假设如果include文件在<>括号中的系统目录应该首先查找，
你的假设不正确。引用gcc手册页：
在标准系统包含目录之前，将搜索由-I命名的目录。
您可能在gcc命令行中指定了-I../kentcsp/src。
请考虑使用-iquote或-idirafter指令。
一般规则，似乎对大多数（如果不是全部的话）都有效编译器，是#include "..."首先在包含包含的文件，然后按#include
<...>的步骤进行。任何-I（或适用于Windows的'/I'）选项都会影响包括因此，包括在项目中（即使项目是"系统标题"）通常使用"..."形式一条完整的相对路径，这样就没有拾取任何东西的风险与项目无关。乍一看，g++似乎替换了stddef.h（所以你得到的是它的版本，而不是/usr/include中的版本），而不是CCD_ 10；由于包含的CCD_ 11在中找不到CCD_则返回到由CCD_ 13指定的列表，然后是编译器添加的一些隐式路径。我会考虑这是个bug。
无论是否存在错误，使用与标准标头同名的标头都不是一个好主意。如果读者看到time.h的包含，不管哪种类型的include，他将立即采用系统头。更改包含文件的名称。
也遇到过类似的问题——原来gcc用头文件玩游戏。有关详细说明，请访问http://ewontfix.com/12/