On Tue, 9 Apr 2013, Jonathan Wakely wrote:
I have been facing a problem while trying to build recent versions of GCC. My goal was to build gcc-4.8.0
Compiling 4.7.0:
Why 4.7.0 not 4.7.2?
4.7.2 was also tried. That build attempt was omitted for space reasons as it
had the same results as 4.7.0.
../gcc-4.7.0/configure --prefix=/usr --enable-shared --enable-static --enable-libada --enable-libssp --enable-lto --with-mpfr=/usr --with-gmp=/usr
If the gmp and mpfr libs are in /usr then you don't need to tell gcc
how to find them.
--disable-werror --enable-__cxa_atexit --enable-threads --enable-threads=posix
Why are you wasting time adding this option *twice* when it's the
default anyway?
Force of habit of running 'configure --help' and copy/pasting output for
options I think I'll need. Redundant options omitted in last build:
../gcc-4.8.0/configure --prefix=/usr --enable-shared --enable-static
--enable-libada --enable-libssp --enable-lto --disable-werror
--enable-__cxa_atexit --enable-tls --enable-objc-gc
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-initfini-array
--with-system-zlib --x-includes=/usr/X11R7/include
--x-libraries=/usr/X11R7/lib --with-x --enable-java-awt=gtk,xlib
--enable-java-gc=boehm --disable-browser-plugin --enable-gconf-peer
--with-python-dir=/lib/python/site-packages --disable-libstdcxx-pch
libtool: compile: g++ -I/usr/src/gcc-4.7.0/libstdc++-v3/../libgcc -I/usr/src/gcc-build-4.7.0/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/usr/src/gcc-build-4.7.0/i686-pc-linux-gnu/libstdc++-v3/include -I/usr/src/gcc-4.7.0/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=chrono.lo -std=gnu++11 -g -O2 -D_GNU_SOURCE -c ../../../../../gcc-4.7.0/libstdc++-v3/src/c++11/chrono.cc -fPIC -DPIC -o chrono.o
cc1plus: error: unrecognized command line option '-std=gnu++11'
This implies that your existing gcc 4.6 is being used to build the
target libraries, which means you're doing something very, very wrong.
Why is the newly built 4.7.0 compiler not being used to compile its
target libraries?
Another person also pointed this out as well and it got me thinking about
environmental variables, which led to the solution.
How did you run 'make'?
'make' and 'make bootstrap' were both tried.
Do you have any strange environment settings?
No, but there IS a config.site file consisting of the following (minus
comments):
host=i686-pc-linux-gnu
sysconfdir=/etc
sharedstatedir=/var/log
localstatedir=/var
localedir=/usr/share/locale
CC="gcc "
CXX="g++ "
F77="gfortran "
ac_cv_KERNEL_LOC="/boot/vmlinux"
ac_cv_MAIL_SPOOL_DIR="/var/spool/mail
autoconfig/configure pull this in, and from past builds of other things I know
it can cause troubles. Moving this aside let the build complete successfully.
What is truly odd is that it was present for 4.6.3 and all past builds with
no issue. Perhaps CXX was getting reset at every run of 'configure' to
"g++ " instead of it using the just-built, new g++. Why this occurred now and
not at 4.6.3 or before in the past I'm not sure.
Adding -fpermissive flag to Makefile:
Don't edit the makefiles by hand, that's not going to help
OK.
It's the same problem in every case, you're using your existing GCC
4.6 to build code that should be built with the new xg++ in the build
dir.
Once config.site was removed it built as expected. I'll run the test suit and
then install. Thank you to all that helped.