Does gcc include disorder?

Question

I ran into that strange problem that the linux C ++ compiler includes files from the local directory instead of the system directory. See Precompiler Output with the (-H) Option. You can see that the system file /usr/include/sched.h unexpectedly includes the time.h header from the local directory, and not the system one. I assume that if the include file is inside the <> brackets, the system directories should look first,

Corresponding line from sched.h : -

#include <time.h> 

Compiler output with (-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 ??? 

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. 

File exists:

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

Answer 1

I assume that if the include file is inside the <> brackets, the system directories should look first,

You are mistakenly accepting. Quoting the gcc man page:

Directories named -I are executed before the standard system includes directories.

You supposedly specified -I../kentcsp/src on your gcc command line.

Consider using the -iquote or -idirafter .

Answer 2

The general rule, which seems to be true for most, if not all compilers, is that #include "..." first looks in the directory that contains the include file, then it is treated as #include <...> . Any -I (or '/ I for Windows) options affect both forms include. For these reasons, it is included in the project (even if it is a project - these are "system headers"), as a rule, use the form "..." , with the full relative path, so that there is no risk to collect something regardless of the project. At first glance, it looks like g ++ is replacing stddef.h (so you get its version, not the one in /usr/include ), but not time.h ; since include stddef.h will not find time.h in the directory in which it is located, it returns to the list specified by -I , and then some implicit paths added by the compiler. I would think this is a mistake.

Error or not, using headers with the same name as standard headers is not a good idea. If the reader sees the inclusion of time.h , no matter what type it includes, it will immediately accept the system header. Change the name of your include file.

Answer 3

It has a similar problem - it turns out that gcc plays games with header files. A great explanation is available at http://ewontfix.com/12/