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

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

Peter Barada wrote:
> I'm trying to build gcc-3.3 configured with:
> /home/peter/work/cvs-local/xgcc/gcc-3.3/configure \
> --with-gcc-version-trigger=/home/peter/work/cvs-local/xgcc/gcc-3.3/gcc/version.c \
> --host=i686-pc-linux-gnu --target=m68k-elf --prefix=/tmp/m68k-elf \
> --enable-languages=c,c++ --with-local-prefix=/tmp/m68k-elf/m68k-elf \

  Recently I built the gcc-3.3 prerelease for m68k-elf (cpu32-elf) and
didn't get any problems.

> --with-headers=/tmp/m68k-elf/m68k-elf/include

  This stupid option is recommended by the gnu.org install instructions,
but using it with newlib-based targets can be dangerous. As is well-
known, it copies the pointed headers to '$prefix/$target/sys-include'
and then tries to fix them to be suitable for ISO C and GNU C during
the GCC-build. Assuming the newlib-headers being broken and not at all
suitable for GCC should sound weird as a thought.

  I assume the newlib-1.11.0 installation still installing its headers
to '$prefix/$target/include', so 'hiding' them from any fixing during
the next GCC-build. Generally this has been/is the de-facto install
place for the target headers, not the '$prefix/$target/sys-include'
and the GCC-manual(s) still document it as the "equivalent to
'/usr/include' in the native GCC".  The need/use of the 'sys-include'
has never been documented very clearly.

  Simply copying the newlib headers from 'newlib/libc/include' into the
'$prefix/$target/include' before starting to configure and build GCC,
and using the '--with-newlib' in configure, should enable one to build
everything, besides in those 'unreal elves as the targets'-cases, for
which at least the 'm68k-elf' and 'mips-elf' belong, but 'arm-elf',
'm32r-elf', 'sh-elf', 'fr30-elf' etc. don't (some magic touch has let
them have a real body)...

  Ok, you have added all kind of 'nice-looking' options into your
configure-command, but the important '--with-newlib' is missing...
If it is missing, the already installed '$prefix/$target/lib' stuff
will be checked for the existing C functions. This option simply tells
that newlib will be used as the chosen C library.

  So my thought is that all your problems come from leaving the
'--with-newlib' away.  Sometimes the so-called 'fixed' newlib headers,
found before the original newlib headers when compiling 'libiberty',
can cause problems too. So you should check your $build/gcc/include
too for the 'fixes' done if using newlib.

> and 'make all' bombs 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
 > -c -DHAVE_CONFIG_H -O2 -g -O2 -I.
 > -I/home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/../include
 > -W -Wall -Wtraditional
 > -pedantic /home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/vsprintf.c
 > -o vsprintf.o

  Ok, newlib includes 'vsprintf()', so producing it into libiberty is
totally vain and clearly an bug, if using newlib as the C library :

E:\usr\local\m68k-elf\lib>..\bin\nm libc.a | grep vsprintf
vsprintf.o:
0000004a T _vsprintf_r
00000000 T vsprintf

  If using some 'local' C-library, this should be built and installed
after doing the 'only GCC'-build with 'make all-gcc ; make install-gcc',
so that the libiberty-configure sees what is in the 'libc.a'...

> /home/peter/work/cvs-local/xgcc/obj/m68k-elf/m68k-elf-gcc/gcc/include/varargs.h:4:2: #error "GCC no longer implements <varargs.h>."
> /home/peter/work/cvs-local/xgcc/obj/m68k-elf/m68k-elf-gcc/gcc/include/varargs.h:5:2: #error "Revise your code to use <stdarg.h>."
> make[2]: *** [vsprintf.o] Error 1
> make[2]: Leaving directory `/home/peter/work/cvs-local/xgcc/obj/m68k-elf/m68k-elf-gcc/m68k-elf/libiberty'
> 
> gcc-3.3/lbiberty/vsprintf.c, indeed includes <varargs.h> (which gcc
> supplise), so if gcc-3.3 has killed support for varargs,h, why is
> libiberty/vsprintf.c trying to include it.

  Which C libraries don't include this function?  For those it will be
built and the important question is how the GCC/libiberty-build behaves 
with them, does it fail or not...

> In fact, why is gcc-3.3 trying to build libiberty with the *target*
 > compiler anyway?

  Your question(s) could also be "For which purposes the extra functions
in 'libiberty' are needed?" and "Why the functions cannot simply be
included into newlib and glibc ?"  Unfortunately I cannot answer to
these, one must review the libiberty documentation...

Cheers, Kai