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]

On 9/28/2012 10:18 AM, Torsten Mueller wrote:
> 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
--
I do not respond to top-posted replies, please don't ask

[Jorgen Grahn]

On Fri, 2012-09-28, Torsten Mueller wrote:
> 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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Torsten Mueller]

Victor Bazarov <v.ba...@comcast.invalid> wrote:

> 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]

Jorgen Grahn <grahn...@snipabacken.se> wrote:

> 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]

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.