问题
I have encountered the strange problem, that linux c++ compiler includes the files from local directory instead of system directory. See the pre-compiler output with (-H) option. It can be seen that system file /usr/include/sched.h suddenly includes time.h header from local directory and not system one. I assume if include file is within <> brackets the system directories should looked up first,
The relevant line from sched.h is:-
#include <time.h>
Compiler output with (-H) option:-
..... /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 ???
Compiler directory search
$ 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.
The file exists:
$ ll /usr/include/time.h
-rw-r--r-- 1 root root 13534 2012-03-07 04:47 /usr/include/time.h
回答1:
I assume if include file is within <> brackets the system directories should looked up first,
You assume incorrectly. Quoting the gcc man page:
Directories named by -I are searched before the standard system include directories.
You presumably specified -I../kentcsp/src on your gcc command line.
Consider using the -iquote or -idirafter directive.
回答2:
The general rule, which seems to be valid for most, if not all
compilers, is that #include "..." first looks in the directory which
contains the file with the include, then procedes as for #include
<...>. Any -I (or '/I' for Windows) options affect both forms of the
include. For this reasons, includes within a project (even if that
project is the "system headers") will usually use the "..." form, with
a full relative path, so that there is no risk of picking up anything
foreign to the project. At first view, it looks like g++ has replaces
stddef.h (so you get its version, and not the one in /usr/include),
but not time.h; since the include stddef.h will not find time.h in
the directory it's in, it falls back to the list specified by -I,
followed by some implicit paths added by the compiler. I'd consider
this a bug.
Bug or not, using headers with the same name as standard headers is not
a good idea. If the reader sees an include of time.h, regardless of
which type of include, he will immediately assume a system header.
Change the name of your include file.
回答3:
Been having a similar problem -- it turns out that gcc plays games with header files. An excellent explanation is available at http://ewontfix.com/12/
来源：https://stackoverflow.com/questions/9893800/gcc-include-order-broken