gcc -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -Icp -I/home/jwakely/src/gcc/gcc -I/home/jwakely/src/gcc/gcc/cp -I/home/jwakely/src/gcc/gcc/../include -I/home/jwakely/src/gcc/gcc/../libcpp/include -I/home/jwakely/build/./gmp -I/home/jwakely/src/gcc/gmp -I/home/jwakely/build/./mpfr -I/home/jwakely/src/gcc/mpfr -I/home/jwakely/src/gcc/mpc/src -I/home/jwakely/src/gcc/gcc/../libdecnumber -I/home/jwakely/src/gcc/gcc/../libdecnumber/dpd -I../libdecnumber /home/jwakely/src/gcc/gcc/cp/lex.c -o cp/lex.o /home/jwakely/src/gcc/gcc/cp/lex.c:559:41: error: macro "ggc_alloc_cleared_lang_decl" passed 1 arguments, but takes just 0 /home/jwakely/src/gcc/gcc/cp/lex.c: In function 'retrofit_lang_decl': /home/jwakely/src/gcc/gcc/cp/lex.c:559: error: 'ggc_alloc_cleared_lang_decl' undeclared (first use in this function) /home/jwakely/src/gcc/gcc/cp/lex.c:559: error: (Each undeclared identifier is reported only once /home/jwakely/src/gcc/gcc/cp/lex.c:559: error: for each function it appears in.) /home/jwakely/src/gcc/gcc/cp/lex.c:600:33: error: macro "ggc_alloc_lang_decl" passed 1 arguments, but takes just 0 /home/jwakely/src/gcc/gcc/cp/lex.c: In function 'cxx_dup_lang_specific_decl': /home/jwakely/src/gcc/gcc/cp/lex.c:600: error: 'ggc_alloc_lang_decl' undeclared (first use in this function) gmake[2]: *** [cp/lex.o] Error 1 gmake[2]: Leaving directory `/home/jwakely/build/gcc' gmake[1]: *** [all-gcc] Error 2 gmake[1]: Leaving directory `/home/jwakely/build' gmake: *** [all] Error 2 Configured with /home/jwakely/src/gcc/configure --prefix=/home/jwakely/gcc/4.x --with-system-zlib --with-gnu-ld --with-gnu-as --disable-nls --disable-libquadmath --enable-languages=c,c++ --disable-libmudflap --disable-bootstrap --disable-libitm --disable-decimal-float Bootstrap compile is gcc version 4.1.3 20080704 prerelease (NetBSD nb2 20081120) Configuring without --disable-bootstrap also fails, in stage 1. The definitions in gtype-desc.h are #define ggc_alloc_lang_decl() ((struct lang_decl *)(ggc_internal_alloc_stat (sizeof (struct lang_decl) MEM_STAT_INFO))) #define ggc_alloc_cleared_lang_decl() ((struct lang_decl *)(ggc_internal_cleared_alloc_stat (sizeof (struct lang_decl) MEM_STAT_INFO)))
Seeing this on powerpc64-unknown-linux-gnu (gcc110) as well as netbsd (gcc70)
I see #define ggc_alloc_lang_decl(SIZE) ((struct lang_decl *)(ggc_internal_alloc_stat (SIZE MEM_STAT_INFO))) on x86_64-linux, with a GCC 4.6 host compiler compiled gengtype.
I also saw this on x86_64-linux (gcc14 in the compile farm) ... not sure what's going on. In all cases it was a completely clean objdir. Will investigate further tonight.
This seems to have been caused by using a sparse checkout from svn (using --set-depth empty) to avoid having thousands of files from libjava and other dirs I don't use. After restoring most of the absent files I get a proper gtype-desc.h The bit that matters seems to be gcc/ada, without that dir being present I get a bad gtype-desc.h even though I'm using --enable-languages=c,c++
(In reply to comment #4) > This seems to have been caused by using a sparse checkout from svn (using > --set-depth empty) to avoid having thousands of files from libjava and other > dirs I don't use. > > After restoring most of the absent files I get a proper gtype-desc.h > > The bit that matters seems to be gcc/ada, without that dir being present I get > a bad gtype-desc.h even though I'm using --enable-languages=c,c++ For GUPC, we build snapshots (and releases) that only have "C"+"C++"+"UPC". Recently, we have run into the failure documented in this bug report for full bootstrap builds (which invoke the C++ compiler) and our truncated source tree. We merge almost weekly with the trunk, fyi. I recall some time back some exchanges on the GCC list regarding the difficulties of releasing sub-parts of the GCC source tree, but don't recall the technical details or the stated policy. Our users run builds on some rather constrained machines, and for them the extra 400MB of source may make a difference. We can confirm that there is something in the 'ada' tree that fixes this build failure. Has a decision been made that sub-setting the GCC tree is unsupported? Or ... perhaps this bug was marked as "RESOLVED INVALID" for a different reason? In any event, we would like to be able to continue to release sub-sets of the GCC source tree if possible, and still run full bootstrap, etc. (note that with --disable-bootstrap we don't see this failure). Please advise.
I closed it as invalid simply because I found the (approximate) reason for the failure, and it was caused by me doing something which I don't /believe/ is required to work, though I would prefer if it did work, and you have a good reason for wanting it to work too. I brought it up on the mailing list: http://gcc.gnu.org/ml/gcc/2012-07/msg00054.html It's probably better to discuss it on the list initially, to see if there is agreement that our use cases are valid, and support for fixing it.
I'm reopening this, unless a relevant maintainer says otherwise I think it's reasonable to expect to be able to build the c and c++ front ends without the ada sources
Fixed by [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01184.html
I received your e-mail and will reply when I'm back in the office after July 30, 2012. Thanks, Nenad