include paths missing

Discussion in 'C++' started by Torsten Mueller, Sep 28, 2012.

  1. 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.
    Torsten Mueller, Sep 28, 2012
    #1
    1. Advertising

  2. 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
    Victor Bazarov, Sep 28, 2012
    #2
    1. Advertising

  3. Torsten Mueller

    Jorgen Grahn Guest

    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 .
    Jorgen Grahn, Sep 29, 2012
    #3
  4. Victor Bazarov <> 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, Sep 29, 2012
    #4
  5. Jorgen Grahn <> 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.
    Torsten Mueller, Sep 29, 2012
    #5
  6. Torsten Mueller

    Jorgen Grahn Guest

    On Sat, 2012-09-29, Torsten Mueller wrote:
    > Jorgen Grahn <> 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 .
    Jorgen Grahn, Sep 29, 2012
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Lack Mr G M
    Replies:
    1
    Views:
    345
    Theodor Rash
    Jul 8, 2003
  2. Noah
    Replies:
    5
    Views:
    750
  3. David Mathog

    ruminations on #include and paths

    David Mathog, Oct 21, 2005, in forum: C Programming
    Replies:
    5
    Views:
    296
  4. Andreas Bogenberger
    Replies:
    3
    Views:
    851
    Andreas Bogenberger
    Feb 22, 2008
  5. Ohad Lutzky

    Paths, gentleman, paths

    Ohad Lutzky, Nov 6, 2006, in forum: Ruby
    Replies:
    2
    Views:
    176
    David Vallner
    Nov 7, 2006
Loading...

Share This Page