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]

Re: How to deal with includes


mike wrote:
> 
> How do you get those include files,
> don't worry, get newlib first and extract
> somewhere(ex:/h/newlib)
> And re-configure your gcc build script.
> (I suggest you delete your build
> directory(/h/crossgcc/build-gnu/gcc/)
> and re mkdir). Remember define your
> include path, like this.
> ./configure --with-headers=/h/newlib/newlib/libc/include

 This causes the headers being 'automagically' copied into
the '$prefix/$target/sys-include', which clashes with the
official docs, the GCC manual, saying :

------------------ clip ----------------------------------
Standard Header File Directories

GCC_INCLUDE_DIR means the same thing for native and cross.
It is where GNU CC stores its private include files, and also
where GNU CC stores the fixed include files.  A cross compiled
GNU CC runs fixincludes on the header files in $(tooldir)/include.
(If the cross compilation header files need to be fixed, they must
be installed before GNU CC is built.  If the cross compilation
header files are already suitable for ANSI C and GNU CC, nothing
special need be done).

CROSS_INCLUDE_DIR is used only for a cross compiler.  GNU CC doesn't
install anything there.

TOOL_INCLUDE_DIR is used for both native and cross compilers.  It is
the place for other packages to install header files that GNU CC will
use.  For a cross-compiler, this is the equivalent of /usr/include.
When you build a cross-compiler, fixincludes processes any header
files in this directory.
------------------ clip ----------------------------------

 Suggesting people to use the '--with-headers=...' is the same as
saying "Please support the bug currently in the GCC sources, taking
it as a 'feature' in the best MS-tradition, and don't send a bug
report"... Ok, this is so obvious bug that I cannot be the only one
who has found this, so I expect it will be corrected or some sane
explanations appearing why the long tradition in using the
'$prefix/$target/include' or the '$(tooldir)/include' (TOOL_INCLUDE_DIR)
should now be changed into the '$prefix/$target/sys-include'
(CROSS_INCLUDE_DIR).

 The question isn't about that the headers in 'sys-include' wouldn't
work, but whether the stuff there should be the standard C headers or
some 3rd party headers. Currently the search order for a cross-cpp is
the following:

------------------------ clip ---------------------------------------
E:\usr\local\lib\gcc-lib\m68k-coff\2_95.2>cpp -v
GNU CPP version 2.95.2 19991024 (release) (68k, Motorola syntax)
#include "..." search starts here:
#include <...> search starts here:
 \usr\local\lib\gcc-lib\m68k-coff\2_95.2\include
 \usr\local\lib\gcc-lib\m68k-coff\2_95.2\..\..\..\..\m68k-coff\sys-include
 \usr\local\lib\gcc-lib\m68k-coff\2_95.2\..\..\..\..\m68k-coff\include
End of search list.
The following default directories have been omitted from the search path:
 /usr/local/lib/gcc-lib/m68k-coff/2_95.2/../../../../include/g++-3
End of omitted list.
^C
------------------------ clip ---------------------------------------

ie. the same as in the document (GCC_INCLUDE_DIR ... TOOL_INCLUDE_DIR).
Whether the 3rd-party etc. headers should be found before the standard
headers or after it is the big question. A native compiler has even two
directories (LOCAL_INCLUDE_DIR and TOOL_INCLUDE_DIR) which will be
searched even before the GCC_INCLUDE_DIR and the '/usr/include' is the
last in the search order...
 
 Ok, my advice is to copy the newlib headers in the sources, from
 
   .../newlib-1.9.0/newlib/libc/include

into the

   $prefix/$target/include

using a single 'cp -r' (recurse subdirs) command. Cannot be any harder
than starting again from scratch, reconfiguring and rebuilding using
the '--with-headers=....'. And the "If the cross compilation header files
are already suitable for ANSI C and GNU CC, nothing special need be done"
suits to the newlib headers quite well. Why the newlib headers cannot be
suitable for GCC in the first place is hard to understand... The gcc-2.8.1
may try to fix them if pointed with the '--with-headers=...', at least the
egcs-1.x.y versions tried that and failed to "fix the already working"...

 Ok, now because of the 'bug' the fixing can be avoided using the
$prefix/$target/include while the '--with-headers=...' forces the fixing
to be done to the pointed headers... Very complicated...

Cheers, Kai


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


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