Re: Building recent gcc (4.8.0) fails

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.






[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux