gcc 包括顺序损坏？答案

【问题标题】：gcc include order broken?gcc 包括顺序损坏？
【发布时间】：2012-04-11 05:39:48
【问题描述】：

我遇到了一个奇怪的问题，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

【问题讨论】：

我确信有办法解决这个问题。但我建议不要将自己的头文件命名为与标准系统头文件相同的名称。
请提供“-H”示例的完整命令行。
听起来您明确设置了自己的包含目录（可能带有-I 标志）？这将导致其他 time.h 文件包含在系统文件中。

标签： c++ linux gcc include-path

【解决方案1】：

遇到了类似的问题——原来 gcc 玩的是带有头文件的游戏。 http://ewontfix.com/12/

提供了很好的解释

【讨论】：

【解决方案2】：

一般规则似乎对大多数人都有效，如果不是全部的话编译器，是 #include "..." 首先在目录中查找包含带有包含的文件，然后按#include <...> 处理。任何 -I（或 Windows 的“/I”）选项都会影响两种形式的包括。出于这个原因，包括在项目中（即使 project 是“系统头文件”）通常使用"..." 形式，带有完整的相对路径，因此没有拾取任何东西的风险对项目陌生。乍一看，看起来 g++ 已经替换了 stddef.h（所以你得到它的版本，而不是/usr/include中的那个），但不是time.h；因为包含stddef.h 不会在其中找到time.h 它所在的目录，它回退到-I指定的列表，其次是编译器添加的一些隐式路径。我会考虑这是一个错误。

Bug 与否，使用与标准标题同名的标题不是一个好主意。如果读者看到 time.h 的包含，无论哪种类型的包含，他会立即假设一个系统头文件。更改包含文件的名称。

【讨论】：

【解决方案3】：

我假设如果包含文件在括号内，则应首先查找系统目录，

你猜错了。引用 gcc 手册页：

-I 命名的目录在标准系统包含目录之前被搜索。

您大概在 gcc 命令行上指定了-I../kentcsp/src。

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

【讨论】：