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

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

[Peter Barada]

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 \
--with-headers=/tmp/m68k-elf/m68k-elf/include --norecursion 

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
In file included from /home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/vsprintf.c:29:
/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.  In fact, why is gcc-3.3
trying to build libiberty with the *target* compiler anyway?

Any suggestions?

-- 
Peter Barada
peter@baradas.org

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

[Erik Christiansen]

On Tue, May 20, 2003 at 01:32:04AM -0400, Peter Barada wrote:
> 
> 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.  In fact, why is gcc-3.3
> trying to build libiberty with the *target* compiler anyway?
> 
> Any suggestions?

   Is there something sytematically wrong with libiberty? Building the
   latest snapshot (gcc-core-20030512) for avr also breaks on libiberty.
   make install has makefile rule problems:

   gcc -c   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings
   -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic
   -Wno-long-long   -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -I.
   -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include
   ../../gcc/gengenrtl.c -o gengenrtl.o
   make[1]: *** No rule to make target `../libiberty/libiberty.a',
   needed by `gengenrtl'.  Stop.
   make[1]: Leaving directory `/usr/local/src/gcc-20030512/obj-avr/gcc'

   In this case, the configure step warned:

>>>
   checking host system type... i686-pc-linux-gnu
   checking target system type... avr-unknown-none
   checking build system type... i686-pc-linux-gnu
   *** This configuration is not supported in the following subdirectories:
     target-libiberty
    (Any other directories should still work fine.)
<<<

   That being the case, why did it bomb, failing to install an
   executable? And is it not unusual for further compilation to be done
   under the install target??

   I hope I'm not mixing in something different on this thread, but at
   first glance it looks like the makefiles are not up to snuff.

Regards,
Erik

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

[Kai Ruottu]

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

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

[Kai Ruottu]

Erik Christiansen wrote:

>    Is there something sytematically wrong with libiberty? Building the
>    latest snapshot (gcc-core-20030512) for avr also breaks on libiberty.
>    make install has makefile rule problems:
> 
>    gcc -c   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings
>    -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic
>    -Wno-long-long   -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -I.
>    -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include
>    ../../gcc/gengenrtl.c -o gengenrtl.o
>    make[1]: *** No rule to make target `../libiberty/libiberty.a',
>    needed by `gengenrtl'.  Stop.

  I just built several GCCs from the same snapshot and in every case the
build-libiberty was produced ok. My build system was RedHat 7.1 with 7.2
and 7.3 stuff used as the update material...  So you should double-check
the '$build/libiberty' subdir, look at the 'config.log' for any possible
failure, do a 'make distclean' there, try to reconfigure only there and
then try to rebuild. Without the 'config.log' it is hard to tell what
went wrong....

>    In this case, the configure step warned:
> 
>    checking host system type... i686-pc-linux-gnu
>    checking target system type... avr-unknown-none
>    checking build system type... i686-pc-linux-gnu
>    *** This configuration is not supported in the following subdirectories:
>      target-libiberty
>     (Any other directories should still work fine.)

  Despite of this, the 'libiberty.a's for the 'host' (and 'build' in
Canadian Crosses, gcc-3.2.x had a serious bug here) system should be 
produced...

Cheers, Kai

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

[DJ Delorie]

> gcc-3.3/lbiberty/vsprintf.c, indeed includes <varargs.h> (which gcc
> supplies), so if gcc-3.3 has killed support for varargs,h, why is
> libiberty/vsprintf.c trying to include it.

That code in libiberty is ancient.  If it's broken now, that means
that whoever dropped support for varargs.h didn't test it well enough.

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

Libiberty is built up to three times: First, for the machine upon
which the build happens, second, for the machine upon which the
resulting tools will run, and third, for the target for which the
tools produce code.

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

[Kaveh R. Ghazi]

 > > gcc-3.3/lbiberty/vsprintf.c, indeed includes <varargs.h> (which gcc
 > > supplies), so if gcc-3.3 has killed support for varargs,h, why is
 > > libiberty/vsprintf.c trying to include it.
 > 
 > That code in libiberty is ancient.  If it's broken now, that means
 > that whoever dropped support for varargs.h didn't test it well enough.

FWIW, it appears to be fixed on mainline.  We can backport vsprintf.c
to 3.3.1 if you think it's worth fixing.  Here's the diff:

--- cvs-egcc-3.3/gcc/libiberty/vsprintf.c	2002-01-22 15:03:29.000000000 -0500
+++ cvs-egcc/gcc/libiberty/vsprintf.c	2003-04-15 16:34:40.516093000 -0400
@@ -26,9 +26,13 @@ the resulting executable to be covered b
 This exception does not however invalidate any other reasons why
 the executable file might be covered by the GNU General Public License. */
 
+#include <ansidecl.h>
+#ifdef ANSI_PROTOTYPES
+#include <stdarg.h>
+#else
 #include <varargs.h>
+#endif
 #include <stdio.h>
-#include <ansidecl.h>
 #undef vsprintf
 
 #if defined _IOSTRG && defined _IOWRT

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

[DJ Delorie]

> FWIW, it appears to be fixed on mainline.  We can backport vsprintf.c
> to 3.3.1 if you think it's worth fixing.  Here's the diff:

If 3.3 complains about varargs, we should backport it.

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

[Peter Barada]

>  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.

Wow, learn something new every day.  After chanig my config to be:

/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 \
--with-newlib --enable-languages=c,c++ \
--with-local-prefix=/tmp/m68k-elf/m68k-elf --norecursion

it builds for me.

What's weird is that gcc-3.2.3 built fine with that configure.  Now
I'm going back and seeing if this configure works for gcc-3.2.3.

Thanx for the pointers...

-- 
Peter Barada
peter@baradas.org

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

[Peter Barada]

>>  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.
>
>Wow, learn something new every day.  After chanig my config to be:
>
>/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 \
>--with-newlib --enable-languages=c,c++ \
>--with-local-prefix=/tmp/m68k-elf/m68k-elf --norecursion
>
>it builds for me.
>
>What's weird is that gcc-3.2.3 built fine with that configure.  Now
>I'm going back and seeing if this configure works for gcc-3.2.3.
>
>Thanx for the pointers...

Now I'm scratching my head.  After blowing away the installed
components and the objects for the bootstrap, newlib, gcc, installed
binutils, rebuild and installed the bootstrap and newlib, 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 \
--with-newlib --enable-languages=c,c++ \
--with-local-prefix=/tmp/m68k-elf/m68k-elf --norecursion

Blows up with:

make[2]: Entering directory `/home/peter/work/cvs-local/xgcc/obj/m68k-elf/m68k-elf-gcc/m68k-elf/libiberty'
if [ x"" != x ]; then \
  /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/hashtab.c -o pic/hashtab.o; \
else true; fi
/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/hashtab.c -o hashtab.o
/home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c: In function `higher_prime_number':
/home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c:133: warning: implicit declaration of function `abort'
/home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c: In function `htab_create':
/home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c:204: error: `free' undeclared (first use in this function)
/home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c:204: error: (Each undeclared identifier is reported only once
/home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c:204: error: for each function it appears in.)
/home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c: In function `htab_try_create':
/home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c:214: error: `calloc' undeclared (first use in this function)
/home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c:214: error: `free' undeclared (first use in this function)
make[2]: *** [hashtab.o] Error 1
make[2]: Leaving directory `/home/peter/work/cvs-local/xgcc/obj/m68k-elf/m68k-elf-gcc/m68k-elf/libiberty'
make[1]: *** [install-target-libiberty] Error 2
make[1]: Leaving directory `/home/peter/work/cvs-local/xgcc/obj/m68k-elf/m68k-elf-gcc'
make: *** [install-gcc] Error 2

I don't have a clue why its failing, especially when it built
before(ok, on top of a previously failed misconfigured build).  Any
suggestions on what to look for?

-- 
Peter Barada
peter@baradas.org

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

[Randy Rude]

On Wed, 2003-05-21 at 00:34, Peter Barada wrote:
> 
> Now I'm scratching my head.  After blowing away the installed
> components and the objects for the bootstrap, newlib, gcc, installed
> binutils, rebuild and installed the bootstrap and newlib, 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 \
> --with-newlib --enable-languages=c,c++ \
> --with-local-prefix=/tmp/m68k-elf/m68k-elf --norecursion
> 
> Blows up with:
> 
> make[2]: Entering directory `/home/peter/work/cvs-local/xgcc/obj/m68k-elf/m68k-elf-gcc/m68k-elf/libiberty'
> if [ x"" != x ]; then \
>   /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/hashtab.c -o pic/hashtab.o; \
> else true; fi
> /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/hashtab.c -o hashtab.o
> /home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c: In function `higher_prime_number':
> /home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c:133: warning: implicit declaration of function `abort'
> /home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c: In function `htab_create':
> /home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c:204: error: `free' undeclared (first use in this function)
> /home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c:204: error: (Each undeclared identifier is reported only once
> /home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c:204: error: for each function it appears in.)
> /home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c: In function `htab_try_create':
> /home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c:214: error: `calloc' undeclared (first use in this function)
> /home/peter/work/cvs-local/xgcc/gcc-3.3/libiberty/hashtab.c:214: error: `free' undeclared (first use in this function)
> make[2]: *** [hashtab.o] Error 1
> make[2]: Leaving directory `/home/peter/work/cvs-local/xgcc/obj/m68k-elf/m68k-elf-gcc/m68k-elf/libiberty'
> make[1]: *** [install-target-libiberty] Error 2
> make[1]: Leaving directory `/home/peter/work/cvs-local/xgcc/obj/m68k-elf/m68k-elf-gcc'
> make: *** [install-gcc] Error 2
> 
> I don't have a clue why its failing, especially when it built
> before(ok, on top of a previously failed misconfigured build).  Any
> suggestions on what to look for?
> 
> -- 
> Peter Barada
> peter@baradas.org
> 

This looks familiar.  Try applying the hashtab.c portion of this patch:
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00726.html

	Randy

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

[Peter Barada]

>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.

I'm wondering why you didn't file a PR back in April against gcc-3.3
that stated that m68k-elf won't build?  At least that way someone
would have *seen* that its broken and hopefully would've applied your
patch(or created a better one).  I'm also wondering how many newlib
targets are affected by this bug?

-- 
Peter Barada                             Peter.Barada@motorola.com
Wizard                                   781-852-2768 (direct)
WaveMark Solutions(A Motorola Company)   781-270-0193 (fax)

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

[Randy Rude]

On Wed, 2003-05-21 at 09:09, 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.
> 
> I'm wondering why you didn't file a PR back in April against gcc-3.3
> that stated that m68k-elf won't build?  At least that way someone
> would have *seen* that its broken and hopefully would've applied your
> patch(or created a better one).  I'm also wondering how many newlib
> targets are affected by this bug?

I have to plead ignorance of the process.  I sent this patch to both you
and gcc-patches.  I assumed that would trigger someone into filing a
PR.  Apparently I assumed incorrectly?

	Randy
 

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

[Joe Buck]

On Wed, May 21, 2003 at 10:55:38AM -0600, Randy Rude wrote:
> On Wed, 2003-05-21 at 09:09, 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.
> > 
> > I'm wondering why you didn't file a PR back in April against gcc-3.3
> > that stated that m68k-elf won't build?  At least that way someone
> > would have *seen* that its broken and hopefully would've applied your
> > patch(or created a better one).  I'm also wondering how many newlib
> > targets are affected by this bug?
> 
> I have to plead ignorance of the process.  I sent this patch to both you
> and gcc-patches.  I assumed that would trigger someone into filing a
> PR.  Apparently I assumed incorrectly?

You assumed incorrectly.  The process really works the other way around;
patches usually get more attention if they fix a PR that gets flagged as
high priority.  So you really want to get your PRs in at the same time
as, or before, your patches.  It's really unlikely that someone will
respond to a proposed patch by creating a PR.


-- 
Q. What's more of a headache than a bug in a compiler.
A. Bugs in six compilers.  -- Mark Johnson

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

[DJ Delorie]

> At least that way someone would have *seen* that its broken and
> hopefully would've applied your patch(or created a better one).

Someone did see the patch, and noted some problems with it.  *I*
didn't see the patch because the subject didn't catch my attention.

http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00738.html

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

[Peter Barada]

>>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.

Has anyone else seen this for other cross targets, and does *anyone*
have an idea how to best get past this?

Thanx in advance!

-- 
Peter Barada
peter@baradas.org

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

[Kai Ruottu]

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

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

[Peter Barada]

>> 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.

Is that after you build/install newlib?  I looked after building
bootstrap, and $prefix/include is empty, and
$prefix/$target/sys-include doesn't contain any header files.

-- 
Peter Barada
peter@baradas.org

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

[Randy Rude]

On Wed, 2003-05-21 at 11:38, DJ Delorie wrote:
> 
> > At least that way someone would have *seen* that its broken and
> > hopefully would've applied your patch(or created a better one).
> 
> Someone did see the patch, and noted some problems with it.  *I*
> didn't see the patch because the subject didn't catch my attention.
> 
> http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00738.html

As noted, I made the bad assumption that submitting the patch would
bring attention to the problem (and the workaround patch solved my
immediate issue).  I haven't had the opportunity to make the suggested
changes to the patch.

Oh well, should I now raise a PR on this (or did someone beat me to it)?

	Randy

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

[DJ Delorie]

> Oh well, should I now raise a PR on this (or did someone beat me to it)?

I don't know.  You'll have to search the database to find out, but if
there isn't a dup, please create a PR for it.

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

[Peter Barada]

>  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.

Thanx for the tip!  Now I can build a complete toolchain
(binutils-2.13, newlib-1.11.0) for --target=m68k-elf using *either*
gcc-3.3, or gcc-3.2.3.

-- 
Peter Barada
peter@baradas.org

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

[Kaveh R. Ghazi]

 > From: DJ Delorie <dj@redhat.com>
 > 
 > > FWIW, it appears to be fixed on mainline.  We can backport vsprintf.c
 > > to 3.3.1 if you think it's worth fixing.  Here's the diff:
 > 
 > If 3.3 complains about varargs, we should backport it.

Done.

(I did "make vsprintf.o" before and after the patch and verified it
fixed the problem.)

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

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

[Joe Buck]

On Fri, May 23, 2003 at 11:29:38AM -0400, Kaveh R. Ghazi wrote:
>  > From: DJ Delorie <dj@redhat.com>
>  > 
>  > > FWIW, it appears to be fixed on mainline.  We can backport vsprintf.c
>  > > to 3.3.1 if you think it's worth fixing.  Here's the diff:
>  > 
>  > If 3.3 complains about varargs, we should backport it.
> 
> Done.
> 
> (I did "make vsprintf.o" before and after the patch and verified it
> fixed the problem.)

Ideally there should be a PR for this problem, so I can point to it in
the 3.3.1 release notes.  Any volunteers to make one?  I would, but I
don't know what platforms that this problem causes a failure for.
 

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

[Joe Buck]

On Fri, May 23, 2003 at 01:58:10PM -0400, Peter Barada wrote:
> >Ideally there should be a PR for this problem, so I can point to it in
> >the 3.3.1 release notes.  Any volunteers to make one?  I would, but I
> >don't know what platforms that this problem causes a failure for.
> 
> I found it for --target=m68k-elf, but I think it shows up for other targets.
> 
> See:
> http://gcc.gnu.org/ml/gcc/2003-05/msg01836.html
> http://gcc.gnu.org/ml/gcc/2003-05/msg01840.html
> http://gcc.gnu.org/ml/gcc/2003-05/msg01904.html

Would you mind writing it up as a PR?  It would suffice to report it
just against m68-elf, mentioning any other target that you know about.

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

[Peter Barada]

>>  > > FWIW, it appears to be fixed on mainline.  We can backport vsprintf.c
>>  > > to 3.3.1 if you think it's worth fixing.  Here's the diff:
>>  > 
>>  > If 3.3 complains about varargs, we should backport it.
>> 
>> Done.
>> 
>> (I did "make vsprintf.o" before and after the patch and verified it
>> fixed the problem.)
>
>Ideally there should be a PR for this problem, so I can point to it in
>the 3.3.1 release notes.  Any volunteers to make one?  I would, but I
>don't know what platforms that this problem causes a failure for.

I found it for --target=m68k-elf, but I think it shows up for other targets.

See:
http://gcc.gnu.org/ml/gcc/2003-05/msg01836.html
http://gcc.gnu.org/ml/gcc/2003-05/msg01840.html
http://gcc.gnu.org/ml/gcc/2003-05/msg01904.html

-- 
Peter Barada                             Peter.Barada@motorola.com
Wizard                                   781-852-2768 (direct)
WaveMark Solutions(A Motorola Company)   781-270-0193 (fax)

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

[Peter Barada]

>Would you mind writing it up as a PR?  It would suffice to report it
>just against m68-elf, mentioning any other target that you know about.

No problem, I'll do it when I get back from the weekend...

-- 
Peter Barada                             Peter.Barada@motorola.com
Wizard                                   781-852-2768 (direct)
WaveMark Solutions(A Motorola Company)   781-270-0193 (fax)

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

[Randy Rude]

On Thu, 2003-05-22 at 11:33, DJ Delorie wrote:
> 
> > Oh well, should I now raise a PR on this (or did someone beat me to it)?
> 
> I don't know.  You'll have to search the database to find out, but if
> there isn't a dup, please create a PR for it.
> 

I created bug #10957 to cover the problem with libiberty.  It appears
the varargs problem is more or less resolved.

	Randy