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: Building GCC as a cross compiler (target=sparc) on RedHat 6.2


David Korn wrote:
> 
>  Yep. You missed providing the target headers where they can be found
> during the cross-compiler build. Drop them in $prefix/$target/sys-include
> (or perhaps $prefix/$target/include ; there seems to be some disagreement
> between different cross targets on this subject, but sys-include always
> works for me) or add the flag --with-headers=/path/to/headers to your
> configure command line.

 The 'include' versus 'sys-include' seems to be a subject which nobody can
be sure... Mumit Khan, the provider of the official Mingw distribution,
claimed that it is now the 'official way' to put the stardard system headers
into the 'sys-include', and the 'www.gnu.org' instructions talk about 'headers'
which should be fixed by GCC because there is something wrong with them. And
I have tried to strugggle against using the '--with-headers' with newlib in
the GCC-build process... Using the option to point to the Linux-kernel headers
while building glibc is quite a different thing.

 The important thing is where the headers are after the GCC installation. If they
are still in the 'sys-include', this is wrong place for them because the
'sys-include' is meant for the 3rd party/substitute headers. The 'sys-' in the
name comes probably from the macro used with the native compiler :

------------------------------ clip ------------------------------------
SYSTEM_INCLUDE_DIR
  Define this macro as a C string constant if you wish to specify a system-
  specific directory to search for header files before the standard directory.
  SYSTEM_INCLUDE_DIR comes before STANDARD_INCLUDE_DIR in the search order.
------------------------------ clip ------------------------------------

while the equivalent for the 'include' is :

------------------------------ clip ------------------------------------
STANDARD_INCLUDE_DIR
  Define this macro as a C string constant if you wish to override the standard
  choice of /usr/include as the default prefix to try when searching for header
  files.
------------------------------ clip ------------------------------------

 If an empty 'sys-include' is created for a cross-compiler and the '-v' used
to show the search order, these things will be seen, here shown with the
'arm-elf' target :

------------------------------ clip ------------------------------------
GNU CPP version 2.95.2 19991024 (release) (ARM/ELF non-Linux)
#include "..." search starts here:
#include <...> search starts here:
 e:\usr\local\lib\gcc-lib\arm-elf\2_95.2\include
 e:\usr\local\lib\gcc-lib\arm-elf\2_95.2\..\..\..\..\arm-elf\sys-include
 e:\usr\local\lib\gcc-lib\arm-elf\2_95.2\..\..\..\..\arm-elf\include
 \usr\local\lib\gcc-lib\arm-elf\2_95.2\include
 \usr\local\lib\gcc-lib\arm-elf\2_95.2\..\..\..\..\arm-elf\sys-include
 \usr\local\lib\gcc-lib\arm-elf\2_95.2\..\..\..\..\arm-elf\include
End of search list.
------------------------------ clip ------------------------------------

 The 'sys-include' will be searched before the 'include' but after the GCC's
own includes (and the fixed ones)...

 Of course the stardard headers being in the 'sys-include' makes the system
to 'work' too, but not in the way Stallman & Co. thought...

 Earlier it was important to run 'fixincludes' for the standard system 'non-ANSI
headers', but nowadays perhaps only the 3rd party ones need any checking. For the
newlib and glibc cases the obvious question is "What is wrong with the headers
in them, why they must be fixed while building GCC ?"

 So some cross targets may need header-fixing, but my opinion is that those
using newlib or glibc don't need it and the 'sys-include' must be left empty...
In any case I wouldn't trust the the things happening during 'fixincludes', but
would check the fixes done to the headers...

 The '--with-headers' copies the pointed headers into 'sys-include' for fixing,
so I'm against using it when the headers don't need any fixing... "Don't fix it,
if it ain't broken". Too often the GCC header-fixing has added bugs there weren't
before the fixing.

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]