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