[Bug c/54179] please split insn-emit.c !
jason.vas.dias at gmail dot com
gcc-bugzilla@gcc.gnu.org
Sun Aug 5 19:49:00 GMT 2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #22 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 19:48:45 UTC ---
RE:
> If you want a C-only compiler then you should just configure with
> "--enable-languages=c" only
of course, I tried that first, but that is no longer possible with gcc-4.7.1+ .
My post to gcc-bugs about this issue was bounced:
Jonathan Wakely jwakely.gcc@gmail.com
Jul 8
Reply
to me, gcc-bugs
Hi,
The gcc-bugs mailing list is for automated emails from our Bugzilla
database. Your question is not about a bug, so would be more
appropriate on the gcc-help mailing list.
The answer to your question is that GCC itself is now built using a
C++ compiler, so it needs to build the C++ compiler to build itself,
see http://gcc.gnu.org/install/configure.html
--enable-build-poststage1-with-cxx
When bootstrapping, build stages 2 and 3 of GCC using a C++
compiler rather than a C compiler. Stage 1 is still built with a C
compiler. This is enabled by default and may be disabled using
--disable-build-poststage1-with-cxx.
Re: gcc-4.7.1 build system question : why is "make bootstrap" with configure
option '--enable-languages=c' building the C++ compiler ?
GCC
x
Jason Vas Dias
Jul 8
Reply
to gcc-bugs
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.dias@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.dias@gmail.com>
So one can no longer build gcc without building c++ and libstdc++ without
the non-standard options you mention.
There really is no need for comments such as these :
> Have you even read the installation
> documentation (http://gcc.gnu.org/install/)?
if you trawl the lists you'd see I've been posting on various gcc issues
once in a while when I come across them since @ 1988 - yes, I have read
the documentation, which still stands in need of updating about being
unable to build c without also building c++ without
'--disable-build-with-cxx --disable-build-poststage1-with-cxx' .
And I hope I'm going to find out that --enable-version-specific-runtime-libs
is now working as expected ! ie. not creating multiple copies of libgcc_s.so
in different places. :-)
These are only niggles, really, after all - I'm only trying help iron them out!
I will build with --enable-gather-statistics once my initial "pure-c" compiler
builds, has passed the "C" test suite, and has built binutils, glibc, gmp, et
al., and then post the results. I'll bet they'll show that it still takes
nearly an hour to generate the assembler for insn-emit.c .
All I'm suggesting is perhaps on machines with less than Xgb RAM the
build scripts might split this file up , and maybe even generate different
sections in parallel - then the insn-emit.c build should take no more than 10
mins or so and maybe even '--enable-checking=all' builds might become feasible.
More information about the Gcc-bugs
mailing list