This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?)
Peter Barada wrote:
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:
------------------------------- clip -------------------------------
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 -------------------------------
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.
But the 'gcc/doc/install.texi' tells:
------------------------------- 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...
The reality in the GCC-build however is that the target headers in the
'$prefix/$target/include' are not noticed at all what becomes to the
header-fixing and checking the existence of some headers among the
target headers. Only the '$prefix/$target/sys-include' will be scanned
for these things. BUT as the Peter's logfile told:
> 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.
Cheers, Kai