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] |
This looks familiar. Try applying the hashtab.c portion of this patch: http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00726.html
Cool, I'll try it and see what happens.
That worked, but I still get the ubiquitous failure rgarding div_t undeclared. See:
http://gcc.gnu.org/ml/gcc/2003-04/msg01321.html http://gcc.gnu.org/ml/gcc/2002-06/msg01602.html
For more information on this well-observed failure. If I remove obj/gcc/include/stdlib.h and stat up the build, gcc-3.3 completes.
Newlib has the 'stdlib.h'. If this is a broken 'fixed' newlib-header, something went wrong in fixinc. If this is a stub which the GCC-build installed because of not seeing the 'stdlib.h' to exist in the '$prefix/$target/include' (where the newlib-install puts it), checking the '$prefix/$target/sys-include' for it instead, I would call this a serious bug. The GCC-docs sources (gcc/doc/headerdirs.texi) tell:
Also the description for the GCC_INCLUDE_DIR tells the same things about the $(tooldir)/include. This directory is just the install directory for the target headers, the '$prefix/$target/include'.
For me this issue is clear: The GCC-build should check the directory $prefix/$target/include for the cross-GCC's target headers and decide whether to try to fix them or not, the '--with-newlib' could trigger this decision. At least the existence of 'limits.h', 'stdlib.h', 'unistd.h' etc. should be checked from the '$prefix/$target/include'.
If the headers are tried to be fixed, the fixing should work ok also in the newlib case.
------------------------------- clip ------------------------------- Some options which only apply to building cross compilers:
--with-headers=dir Specifies a directory which has target include files. This option is required when building a cross compiler, if `prefix/target/sys-include' doesn't pre-exist.
These include files will be copied into the `gcc' install directory. fixincludes will be run on these files to make them compatible with GCC. ------------------------------- clip -------------------------------
Ok, let's assume that the '$prefix/$target/sys-include' pre-exists. In the RedHat EDK cross-tools for Linux targets it had the kernel headers ('asm' and 'linux' subdirs), the '.../include' had the usual Linux-glibc headers. I have all the 3rd party headers which describe the I/O-addresses and bits in chips there. In both cases these are 'target include files' and seemingly the GCC-build tries to fix also these for GCC... After reading these two places from the GCC-manuals, one should have some kind of thought what will happen to the target headers during the GCC-build... Or what ?
What on earth this explanation for '--with-headers' tries to say? All the experienced cross-GCC builders know that the 'sys-include' definitely isn't the place for the standard target headers for a cross-GCC, but the 'include' is and the text: "For a cross-compiler, this is the equivalent of `/usr/include'", in the GCC-manual agrees with them...
> Blows up with: > > /home/peter/work/cvs-local/xgcc/obj/m68k-elf/m68k-elf-gcc/gcc/xgcc > -B/home/peter/work/cvs-local/xgcc/obj/m68k-elf/m68k-elf-gcc/gcc/ > -B/tmp/m68k-elf/m68k-elf/bin/ > -B/tmp/m68k-elf/m68k-elf/lib/ > -isystem /tmp/m68k-elf/m68k-elf/include <---- !!!
the '$prefix/$target/include' has been taken as the directory where the target headers are expected to exist.
What the GCC-build now does, clashes with the GCC-documentation and this I call being a serious bug!
Has anyone else seen this for other cross targets, and does *anyone* have an idea how to best get past this?
Maybe we should bomb the GCC-developers with bug reports about the misuse of the '$prefix/$target/sys-include' now... During the last years I have now and then try to report this, but with no response at all...
The current workaround I now use is to symlink all those checked headers: 'stdlib.h', 'unistd.h', 'string.h' and 'limits.h' into '$prefix/$target/sys-include' from '$prefix/$target/include', so that they will not be replaced with stubs during the GCC-build.
------ 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] |