2012-03-27 5 views
4

Ich habe das seltsame Problem festgestellt, dass Linux C++ - Compiler die Dateien aus dem lokalen Verzeichnis anstelle von Systemverzeichnis enthält. Siehe die Pre-Compiler-Ausgabe mit der Option (-H). Es kann, dass die Systemdatei zu sehen /usr/include/sched.h plötzlich time.h Header aus lokalem Verzeichnis enthält und nicht System ein. Ich gehe davon aus, wenn Include-Datei befindet sich in <> die Systemverzeichnisse Klammern zuerst nachgeschlagen sollte,gcc include Auftrag gebrochen?

Die entsprechende Zeile aus sched.h ist: -

#include <time.h> 

Compiler Ausgabe mit (-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 Verzeichnis Meer rch

$ 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. 

Die Datei existiert:

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

Ich bin mir sicher, es gibt eine Möglichkeit, dies zu lösen. Aber ich würde empfehlen, Ihre eigenen Header-Dateien nicht identisch mit Standard-System-Headern zu benennen. –

+2

Bitte geben Sie die vollständige Befehlszeile für das Beispiel "-H" an. –

+2

Klingt wie Sie explizit Ihre eigenen Include-Verzeichnisse (möglicherweise mit "-I" Flag)? Das würde dazu führen, dass andere "time.h" -Dateien über das System eingefügt werden. – birryree

Antwort

8

Ich gehe davon aus, wenn die Datei enthalten ist innerhalb <> die Systemverzeichnisse Klammern zuerst nachgeschlagen sollte,

Sie falsch annehmen. Zitieren der GCC-Man-Seite:

Verzeichnisse mit dem Namen -I werden vor dem Standardsystem einschließlich Verzeichnisse gesucht.

Sie haben vermutlich -I../kentcsp/src in Ihrer gcc-Befehlszeile angegeben.

Verwenden Sie die -iquote oder -idirafter Richtlinie.

2

Die allgemeine Regel, die für die gültigste zu sein scheint, wenn nicht alle Compiler ist, dass #include "..." erste Blicke in dem Verzeichnis, das die Datei mit dem Include enthalten, dann procedes wie für #include <...>. Alle Optionen -I (oder '/ I' für Windows) betreffen beide Formen des Include. Aus diesem Grund wird in einem Projekt (auch wenn das -Projekt die "System-Header" ist) normalerweise das Formular "..." mit einen vollständigen relativen Pfad verwendet, so dass kein Risiko besteht, irgendetwas vom Projekt abzuziehen . Auf den ersten Blick sieht es so aus, als ob g ++ stddef.h ersetzt (so erhalten Sie seine Version, und nicht die in /usr/include), , aber nicht time.h; Da das Include stddef.htime.h in das Verzeichnis nicht finden wird, fällt es in die Liste zurück, die von -I, gefolgt von einigen impliziten Pfaden angegeben wird, die vom Compiler hinzugefügt werden. Ich würde dies einen Fehler betrachten.

Fehler oder nicht, Header mit dem gleichen Namen wie Standard-Header verwenden ist nicht eine gute Idee.Wenn der Leser ein Include von time.h sieht, unabhängig von welche Art von Include, wird er sofort einen System-Header annehmen. Ändern Sie den Namen Ihrer Include-Datei.

0

Sie hatten ein ähnliches Problem - es stellt sich heraus, dass gcc Spiele mit Header-Dateien spielt. Eine ausgezeichnete Erklärung gibt es unter http://ewontfix.com/12/