This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
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...
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |