* failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) @ 2003-05-20 6:12 Peter Barada 2003-05-20 6:53 ` Erik Christiansen ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Peter Barada @ 2003-05-20 6:12 UTC (permalink / raw) To: gcc, crossgcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-20 6:12 failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) Peter Barada @ 2003-05-20 6:53 ` Erik Christiansen 2003-05-20 10:53 ` Kai Ruottu 2003-05-20 10:44 ` Kai Ruottu 2003-05-20 16:19 ` DJ Delorie 2 siblings, 1 reply; 26+ messages in thread From: Erik Christiansen @ 2003-05-20 6:53 UTC (permalink / raw) To: Peter Barada; +Cc: gcc, crossgcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-20 6:53 ` Erik Christiansen @ 2003-05-20 10:53 ` Kai Ruottu 0 siblings, 0 replies; 26+ messages in thread From: Kai Ruottu @ 2003-05-20 10:53 UTC (permalink / raw) To: Erik Christiansen; +Cc: Peter Barada, gcc, crossgcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-20 6:12 failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) Peter Barada 2003-05-20 6:53 ` Erik Christiansen @ 2003-05-20 10:44 ` Kai Ruottu 2003-05-21 4:55 ` Peter Barada 2003-05-20 16:19 ` DJ Delorie 2 siblings, 1 reply; 26+ messages in thread From: Kai Ruottu @ 2003-05-20 10:44 UTC (permalink / raw) To: Peter Barada; +Cc: gcc, crossgcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-20 10:44 ` Kai Ruottu @ 2003-05-21 4:55 ` Peter Barada 2003-05-21 7:13 ` Peter Barada 0 siblings, 1 reply; 26+ messages in thread From: Peter Barada @ 2003-05-21 4:55 UTC (permalink / raw) To: kai.ruottu; +Cc: gcc, crossgcc > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-21 4:55 ` Peter Barada @ 2003-05-21 7:13 ` Peter Barada 2003-05-21 15:05 ` Randy Rude 0 siblings, 1 reply; 26+ messages in thread From: Peter Barada @ 2003-05-21 7:13 UTC (permalink / raw) To: peter; +Cc: kai.ruottu, gcc, crossgcc >> 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-21 7:13 ` Peter Barada @ 2003-05-21 15:05 ` Randy Rude 2003-05-21 15:38 ` Peter Barada 0 siblings, 1 reply; 26+ messages in thread From: Randy Rude @ 2003-05-21 15:05 UTC (permalink / raw) To: Peter Barada; +Cc: kai.ruottu, gcc, crossgcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-21 15:05 ` Randy Rude @ 2003-05-21 15:38 ` Peter Barada 2003-05-21 16:56 ` Randy Rude ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Peter Barada @ 2003-05-21 15:38 UTC (permalink / raw) To: randy.rude; +Cc: peter, kai.ruottu, gcc, crossgcc >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) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-21 15:38 ` Peter Barada @ 2003-05-21 16:56 ` Randy Rude 2003-05-21 17:28 ` Joe Buck 2003-05-21 17:39 ` DJ Delorie 2003-05-22 3:14 ` Peter Barada 2 siblings, 1 reply; 26+ messages in thread From: Randy Rude @ 2003-05-21 16:56 UTC (permalink / raw) To: Peter Barada; +Cc: peter, gcc, crossgcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-21 16:56 ` Randy Rude @ 2003-05-21 17:28 ` Joe Buck 0 siblings, 0 replies; 26+ messages in thread From: Joe Buck @ 2003-05-21 17:28 UTC (permalink / raw) To: Randy Rude; +Cc: Peter Barada, peter, gcc, crossgcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-21 15:38 ` Peter Barada 2003-05-21 16:56 ` Randy Rude @ 2003-05-21 17:39 ` DJ Delorie 2003-05-22 14:59 ` Randy Rude 2003-05-22 3:14 ` Peter Barada 2 siblings, 1 reply; 26+ messages in thread From: DJ Delorie @ 2003-05-21 17:39 UTC (permalink / raw) To: pbarada; +Cc: randy.rude, peter, kai.ruottu, gcc, crossgcc > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-21 17:39 ` DJ Delorie @ 2003-05-22 14:59 ` Randy Rude 2003-05-22 17:36 ` DJ Delorie 0 siblings, 1 reply; 26+ messages in thread From: Randy Rude @ 2003-05-22 14:59 UTC (permalink / raw) To: DJ Delorie; +Cc: pbarada, peter, kai.ruottu, gcc, crossgcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-22 14:59 ` Randy Rude @ 2003-05-22 17:36 ` DJ Delorie 2003-05-23 19:40 ` Randy Rude 0 siblings, 1 reply; 26+ messages in thread From: DJ Delorie @ 2003-05-22 17:36 UTC (permalink / raw) To: randy.rude; +Cc: pbarada, peter, kai.ruottu, gcc, crossgcc > 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-22 17:36 ` DJ Delorie @ 2003-05-23 19:40 ` Randy Rude 0 siblings, 0 replies; 26+ messages in thread From: Randy Rude @ 2003-05-23 19:40 UTC (permalink / raw) To: DJ Delorie; +Cc: pbarada, peter, kai.ruottu, gcc, crossgcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-21 15:38 ` Peter Barada 2003-05-21 16:56 ` Randy Rude 2003-05-21 17:39 ` DJ Delorie @ 2003-05-22 3:14 ` Peter Barada 2003-05-22 12:17 ` Kai Ruottu 2 siblings, 1 reply; 26+ messages in thread From: Peter Barada @ 2003-05-22 3:14 UTC (permalink / raw) To: pbarada; +Cc: randy.rude, kai.ruottu, gcc, crossgcc >>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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-22 3:14 ` Peter Barada @ 2003-05-22 12:17 ` Kai Ruottu 2003-05-22 13:33 ` Peter Barada 2003-05-23 3:25 ` Peter Barada 0 siblings, 2 replies; 26+ messages in thread From: Kai Ruottu @ 2003-05-22 12:17 UTC (permalink / raw) To: Peter Barada; +Cc: pbarada, randy.rude, gcc, crossgcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-22 12:17 ` Kai Ruottu @ 2003-05-22 13:33 ` Peter Barada 2003-05-23 3:25 ` Peter Barada 1 sibling, 0 replies; 26+ messages in thread From: Peter Barada @ 2003-05-22 13:33 UTC (permalink / raw) To: kai.ruottu; +Cc: pbarada, randy.rude, gcc, crossgcc >> 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-22 12:17 ` Kai Ruottu 2003-05-22 13:33 ` Peter Barada @ 2003-05-23 3:25 ` Peter Barada 1 sibling, 0 replies; 26+ messages in thread From: Peter Barada @ 2003-05-23 3:25 UTC (permalink / raw) To: kai.ruottu; +Cc: pbarada, randy.rude, gcc, crossgcc > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-20 6:12 failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) Peter Barada 2003-05-20 6:53 ` Erik Christiansen 2003-05-20 10:44 ` Kai Ruottu @ 2003-05-20 16:19 ` DJ Delorie 2003-05-20 21:06 ` Kaveh R. Ghazi 2 siblings, 1 reply; 26+ messages in thread From: DJ Delorie @ 2003-05-20 16:19 UTC (permalink / raw) To: peter; +Cc: gcc, crossgcc > 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-20 16:19 ` DJ Delorie @ 2003-05-20 21:06 ` Kaveh R. Ghazi 2003-05-20 21:44 ` DJ Delorie 0 siblings, 1 reply; 26+ messages in thread From: Kaveh R. Ghazi @ 2003-05-20 21:06 UTC (permalink / raw) To: dj; +Cc: crossgcc, gcc-patches, gcc, peter > > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-20 21:06 ` Kaveh R. Ghazi @ 2003-05-20 21:44 ` DJ Delorie 2003-05-23 15:30 ` Kaveh R. Ghazi 0 siblings, 1 reply; 26+ messages in thread From: DJ Delorie @ 2003-05-20 21:44 UTC (permalink / raw) To: ghazi; +Cc: crossgcc, gcc-patches, gcc, peter > 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-20 21:44 ` DJ Delorie @ 2003-05-23 15:30 ` Kaveh R. Ghazi 2003-05-23 17:49 ` Joe Buck 0 siblings, 1 reply; 26+ messages in thread From: Kaveh R. Ghazi @ 2003-05-23 15:30 UTC (permalink / raw) To: dj; +Cc: crossgcc, gcc-patches, gcc, peter > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-23 15:30 ` Kaveh R. Ghazi @ 2003-05-23 17:49 ` Joe Buck 2003-05-23 18:17 ` Peter Barada 0 siblings, 1 reply; 26+ messages in thread From: Joe Buck @ 2003-05-23 17:49 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: dj, crossgcc, gcc-patches, gcc, peter 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-23 17:49 ` Joe Buck @ 2003-05-23 18:17 ` Peter Barada 2003-05-23 18:17 ` Joe Buck 0 siblings, 1 reply; 26+ messages in thread From: Peter Barada @ 2003-05-23 18:17 UTC (permalink / raw) To: jbuck; +Cc: ghazi, dj, crossgcc, gcc-patches, gcc, peter >> > > 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) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-23 18:17 ` Peter Barada @ 2003-05-23 18:17 ` Joe Buck 2003-05-23 18:39 ` Peter Barada 0 siblings, 1 reply; 26+ messages in thread From: Joe Buck @ 2003-05-23 18:17 UTC (permalink / raw) To: Peter Barada; +Cc: ghazi, dj, crossgcc, gcc-patches, gcc, peter 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) 2003-05-23 18:17 ` Joe Buck @ 2003-05-23 18:39 ` Peter Barada 0 siblings, 0 replies; 26+ messages in thread From: Peter Barada @ 2003-05-23 18:39 UTC (permalink / raw) To: jbuck; +Cc: Peter.Barada, ghazi, dj, crossgcc, gcc-patches, gcc, peter >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) ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2003-05-23 19:37 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-05-20 6:12 failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) Peter Barada 2003-05-20 6:53 ` Erik Christiansen 2003-05-20 10:53 ` Kai Ruottu 2003-05-20 10:44 ` Kai Ruottu 2003-05-21 4:55 ` Peter Barada 2003-05-21 7:13 ` Peter Barada 2003-05-21 15:05 ` Randy Rude 2003-05-21 15:38 ` Peter Barada 2003-05-21 16:56 ` Randy Rude 2003-05-21 17:28 ` Joe Buck 2003-05-21 17:39 ` DJ Delorie 2003-05-22 14:59 ` Randy Rude 2003-05-22 17:36 ` DJ Delorie 2003-05-23 19:40 ` Randy Rude 2003-05-22 3:14 ` Peter Barada 2003-05-22 12:17 ` Kai Ruottu 2003-05-22 13:33 ` Peter Barada 2003-05-23 3:25 ` Peter Barada 2003-05-20 16:19 ` DJ Delorie 2003-05-20 21:06 ` Kaveh R. Ghazi 2003-05-20 21:44 ` DJ Delorie 2003-05-23 15:30 ` Kaveh R. Ghazi 2003-05-23 17:49 ` Joe Buck 2003-05-23 18:17 ` Peter Barada 2003-05-23 18:17 ` Joe Buck 2003-05-23 18:39 ` Peter Barada
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).