OK, so I'm reconfiguring with : --enable-languages=c --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-stage1-checking=all --enable-stage1-languages=c but why should I have to ? Shouldn't "--enable-languages=c" be enough to disable building the C++ compiler and libstdc++ ? Thanks & Regards, Jason
On Sun, Jul 8, 2012 at 4:06 PM, Jason Vas Dias <jason.vas.d...@gmail.com> wrote: > 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>