Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?)

[Kai Ruottu <kai.ruottu@luukku.com>]

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