Hi - I've been regularly building gcc for nearly two decades, and now attempting to build a bootstrap "C" only gcc-4.7.1 sufficient only to build binutils (my initial first step is always to rebuild binutils with the bootstrap "C" only compiler before doing a complete "make" with "--enable-languages=all" - a shame that support for configuring and building binutils along with gcc has been withdrawn , so now I attempt to rebuild binutils separately with the "C" only bootstrap compiler) .
Now this doesn't work - building "C"-only ( --enable-languages=c ) bootstrap fails building "C++" : /mnt/sda3/gcc/./prev-gcc/g++ -B/mnt/sda3/gcc/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/usr/build2/gcc/gcc-4.7.1/libstdc++-v3/libsupc++ -L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o i386-c.o default-c.o \ cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lcloog -lppl_c -lppl -lpwl -lgmpxx -lmpc -lmpfr -lgmp -rdynamic -ldl -lz lto/lto.o: In function `lto_ft_typed(tree_node*)': lto.c:(.text+0x326): undefined reference to `tree_code_type' lto/lto.o: In function `lto_ft_common(tree_node*)': lto.c:(.text+0x38b): undefined reference to `tree_code_type' lto/lto.o: In function `lto_ft_decl_common(tree_node*)': lto.c:(.text+0x3fb): undefined reference to `tree_code_type' lto.c:(.text+0x432): undefined reference to `tree_code_type' lto.c:(.text+0x469): undefined reference to `tree_code_type' lto/lto.o:lto.c:(.text+0x49e): more undefined references to `tree_code_type' follow Boy, does it really mean it when it says "more undefined references to `tree_code_type' follow" : $ grep 'undefined reference' make.bootstrap-cntnd.log | wc -l 18127 My config.log command : generated by GNU Autoconf 2.64. Invocation command line was $ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr --libdir=/usr/lib64 --with-cpu-32=i686 --with-cpu-64=k8 --enable-languages=c --enable-targets=all --enable-multi lib --enable-threads=posix --enable-tls --enable-lto --enable-shared --enable-checking=release --with-build-time-tools=/usr/bin --with-ld=/usr/bin/ld --with-gnu-ld -- with-as=/usr/bin/as --with-gnu-as --enable-version-specific-runtime-libs --with-system-zlib --without-included-gettext --enable-bootstrap --enable-serial-configure -- host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu ## --------- ## ## Platform. ## ## --------- ## hostname = jvdspc uname -m = x86_64 uname -r = 3.4.4-jvd+ uname -s = Linux uname -v = #4 SMP Fri Jul 6 20:19:44 GMT 2012 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown I configured with above command and did: $ make -j2 bootstrap 2>&1 | tee make.bootstrap.log This built fine overnight , and when I woke up in the morning the machine was in a hard lock-up state (overheating - I'm also investigating a kernel bug on this issue). The build had created the "stage_final" file and a working prev-gcc/xgcc - Can anyone suggest why making a "bootstrap" "C" "--enable-languages=c" compiler should then go on to build "C++" ? I'm pretty sure the above error would not have occurred without the kernel lock-up and interruption, but nevertheless, I didn't ask the gcc build system to build C++ yet, so why did it do so ? Any ideas / comments would be much appreciated , Jason Vas Dias (a Software Engineer) <jason.vas.d...@gmail.com>
