include paths missing

[Torsten Mueller]

I have an interesting g++ compiler question.

(I know this is more a C++ language group but I think many people here
use(d) gcc.)

I specify -I. and -I../.. during the g++ invocation. But the compiler
doesn't know these paths during compilation. Why?

Look at this example:

$ g++ -v -I. -I../.. -c config.cc

The -v makes gcc dump the following list before compilation:

[...]
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/i686-pc-linux-gnu
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/backward
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/include
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/include-fixed
/usr/include
End of search list.
End of search list.
[...]

I have another machine where . and ../.. are truely mentioned at the top
of the list and everything is fine. But here g++ doesn't find the
headers. What could be a reason for this? I really have no idea. The
environment variables CFLAGS, CCFLAGS, CXXFLAGS, CPPFLAGS are empty.

Additional question: is -I. default or not? On the other machine, where
everything works fine, I can remove -I. and it still compiles well.

g++ 4.7.1 on Arch Linux

T.M.

 

[Victor Bazarov]

I have an interesting g++ compiler question.

(I know this is more a C++ language group

"More"? It *is* a C++ language group. Not more, only.

but I think many people here
use(d) gcc.)

Many people here dr[i,o]ve cars. So, if I have a question about cars, I
should ask it here, right?

[..]

g++ 4.7.1 on Arch Linux

Go to gnu.gcc.* hierarchy or comp.os.linux.development.* hierarchy.

V

 

[Jorgen Grahn]

I have an interesting g++ compiler question. ....
Additional question: is -I. default or not? On the other machine, where
everything works fine, I can remove -I. and it still compiles well.

At least with gcc, #include "foo.h" will search . by default, but
#include <foo.h> will only search the standard include path and
whatever extra places you tell it to search. The documentation should
tell you the exact rules.

I use the "foo.h" (or "foo/bar.h" or "../foo.h") form when I refer to
files in the same project/code base.

I use <foo.h> or <foo/bar.h> when I want to treat foo.h as a
potentially separate library.

No idea if this is universal. Even if the standard doesn't say, I
think it makes sense for most/all compilers to do it like that.

/Jorgen

 

[Torsten Mueller]

Many people here dr[i,o]ve cars. So, if I have a question about cars,
I should ask it here, right?

Thank you, man. I tried two other, more compiler specific groups in
gnu.gcc.* and gnu.g++.* before, nobody answered because these groups
have almost no traffic anymore. So I tried it here and you appeared on
the horizon ...

T.M.

 

[Torsten Mueller]

At least with gcc, #include "foo.h" will search . by default, but
#include <foo.h> will only search the standard include path and
whatever extra places you tell it to search. The documentation should
tell you the exact rules.

The documentation tells exactly this. But the compiler on this specific
machine hasn't read the documentation. Headers in the source file's
directory are not found at all independent from wheather -I. is
specified or not. There must be some possibility in the compilers
configuration to achieve this, but where???

T.M.

 

[Jorgen Grahn]

The documentation tells exactly this. But the compiler on this specific
machine hasn't read the documentation. Headers in the source file's
directory are not found at all independent from wheather -I. is
specified or not. There must be some possibility in the compilers
configuration to achieve this, but where???

No idea. Maybe 'g++ -dumpspecs' helps?

That's all I can say, except double-check and if it /does/ behave
that weirdly, get yourself a working installation somehow. It's hard
to do your work when you cannot trust the tools.

/Jorgen