This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC/G++ and include directories


Jan Van Belle <Jan.Van_Belle@alcatel.be> wrote:

> I'm not really sure wether this is the good list for this
> question. I hope anyway that one of you will be able to help
> me out...

 Maybe this list is just as good as anyone else for learning
these basic things...

 Your problem is related to using GCC, native or cross, and not
knowing how to use GCC is after all very common because so few
nowadays care to build or download the "Using and Porting..."
And although the manual would be available, reading it can be
hard :-)

> I am trying to compile the latest gcc version (v3.3.1) on my
> solaris-2.8 machine. It builds normally, and for normal use
> the compiler works perfect.
> But when looking under the hood, it seems that it takes the
> OLD include files instead of the newly-patched ones (I'm
> speaking for C++, didn't encounter the problem on C ), thus
> generating on certain packages tons of errors.

 You can always check where your CPP searches its headers when
using C++, by giving the options '-lang-c++' and '-v' to the
preprocessor driver, like :

E:\usr\local\bin>cpp-msp430-elf-32 -Wp,-lang-c++,-v
GNU CPP version 3.2.2 (MinGW patched) (cpplib) (GNU assembler syntax)
ignoring nonexistent directory "NONE/include"
#include "..." search starts here:
#include <...> search starts here:
 e:/usr/local/include/c++/3.2.2
 e:/usr/local/include/c++/3.2.2/msp430-elf
 e:/usr/local/include/c++/3.2.2/backward
 e:/usr/local/include
 e:/usr/local/lib/gcc-lib/msp430-elf/3.2.2/include
 e:/usr/local/msp430-elf/sys-include
 e:/usr/local/msp430-elf/include
 /usr/local/include/c++/3.2.2
 /usr/local/include/c++/3.2.2/msp430-elf
 /usr/local/include/c++/3.2.2/backward
 /usr/local/include
 /usr/local/lib/gcc-lib/msp430-elf/3.2.2/include
 /usr/local/msp430-elf/sys-include
 /usr/local/msp430-elf/include
End of search list.

 As you can see, your C++ headers should be sought from:

/dumpdisk/localdisk/compiler/test/include/c++/3.3.1
/dumpdisk/localdisk/compiler/test/include/c++/3.3.1/sparc-sun-solaris2.8
/dumpdisk/localdisk/compiler/test/include/c++/3.3.1/backward

because of your chosen $prefix and $target, in just this order and there
shouldn't be any 'old' C++ headers there... Then your C headers should be
sought from:

LOCAL_INCLUDE_DIR:
  /dumpdisk/localdisk/compiler/test/include

TOOL_INCLUDE_DIR:
  /dumpdisk/localdisk/compiler/test/sparc-sun-solaris2.8/include

and from GCC_INCLUDE_DIR:
  /dumpdisk/localdisk/compiler/test/lib/gcc-lib/sparc-sun-solaris2.8/3.3.1/include

before the place for the original old Solaris2.8 standard headers in:
  /usr/include

 The LOCAL_INCLUDE_DIR is for the 3rd-party headers (Oracle, tcl/tk etc.) and no
standard headers should be there. The TOOL_INCLUDE_DIR shouldn't have anything,
or at least there is no standard for what it should have...

 A cross-GCC searches the system (specific) headers in $prefix/$target/sys-include
before the standard headers in $prefix/$target/include, ie. as default the native
'/usr/include' has been replaced with two directories. A native GCC can have an
equivalent to the 'sys-include' if the SYSTEM_INCLUDE_DIR has been defined in its
config files (BeOS and Mach are two, Windoze with its W32API-headers could be one
more but surprisingly neither Cygwin nor MinGW use a separate directory for the
'w32api' headers).

 You should check your situation with your 'cpp' and with the given basic 'debug
the GCC installation' options... Generally toying with the '--help' option and
experimenting with the options is always recommended. The manual(s) should always
tell much more than the '--help' alone, so getting the GCC, CPP, AS, LD etc.
manuals by building them into PDF (pdftex/pdflatex etc.) or something is highly
recommended. Building only the GCC binaries without any manuals is not very good
choice... Ok, there are people with built-in manuals in their heads but...

 Experimenting with the interesting options may be the only way to see what they
might do, I had to learn to use the new 'cpp-drivers' when the 'cpp', then 'cpp0',
disappeared and was integrated into 'cc1' in gcc-3.2.x or gcc-3.3.x... Ok, one
can try the '-v' alone and get all kind of extra garbage, but I like to command
the built-in 'cpp' in 'cc1' and get just what I want...
  
> Can someone tell me how I can tell the compiler where to
> look FIRST for its include files? He finds them, but it're
> the old ones...

 The 'gcc/cppdefaults.h' (or '.c') should define the search order
and as my MSP430-output tells, I have added the LOCAL_INCLUDE_DIR
to be searched by cross-GCCs too (the 3rd party headers like the
tcl/tk ones may be target-independent and common for all possible
targets). So the previous default search order can be changed but
not without a sane reason.

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]