Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > include paths missing

Reply
Thread Tools

include paths missing

 
 
Torsten Mueller
Guest
Posts: n/a
 
      09-28-2012
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.
 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      09-28-2012
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
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      09-29-2012
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 .
 
Reply With Quote
 
Torsten Mueller
Guest
Posts: n/a
 
      09-29-2012
Victor Bazarov <(E-Mail Removed)> 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.
 
Reply With Quote
 
Torsten Mueller
Guest
Posts: n/a
 
      09-29-2012
Jorgen Grahn <(E-Mail Removed)> 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.
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      09-29-2012
On Sat, 2012-09-29, Torsten Mueller wrote:
> Jorgen Grahn <(E-Mail Removed)> 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???


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

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

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
/* #include <someyhing.h> */ => include it or do not include it?That is the question .... Andreas Bogenberger C Programming 3 02-22-2008 10:53 AM
Paths, gentleman, paths Ohad Lutzky Ruby 2 11-07-2006 02:15 AM
ruminations on #include and paths David Mathog C Programming 5 10-21-2005 11:45 PM
Convert between Windows style paths and POSIX style paths Noah Python 5 07-11-2003 09:25 PM
Re: Building Python - how to set include and lib paths? Lack Mr G M Python 1 07-08-2003 08:40 AM



Advertisments