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 ищутся до того, как стандартная система включает каталоги.

Вы предположительно указали -I../kentcsp/src в командной строке gcc.

Попробуйте использовать директиву -iquote или -idirafter.

Answer 2

Общее правило, которое, кажется, справедливо для большинства, если не для всех компиляторы, это то, что #include "..." сначала смотрит в каталог, который содержит файл с включением, затем выполняется как для #include <...>. Любые параметры -I (или «/ I» для Windows) влияют на обе формы включают. По этим причинам включает в проект (даже если это Project - это «системные заголовки»), обычно используется форма "...", с полный относительный путь, так что нет риска что-либо подобрать чуждый проекту. На первый взгляд, похоже, что g ++ заменяет stddef.h (так что вы получите его версию, а не ту, что в /usr/include), но не time.h; поскольку include stddef.h не найдет time.h в каталог, в котором он находится, возвращается к списку, указанному -I, сопровождаемый некоторыми неявными путями, добавленными компилятором. Я бы подумал это ошибка.

Ошибка или нет, использование заголовков с тем же именем, что и стандартные заголовки, не хорошая идея. Если читатель видит включение time.h, независимо от какой тип включить он сразу примет системный заголовок. Измените имя вашего включаемого файла.

Answer 3

Возникла похожая проблема - оказалось, что gcc играет в игры с заголовочными файлами. Отличное объяснение доступно на http://ewontfix.com/12/