0

I have CentOS 7.2 1511 (gcc 4.8.5 20150623 (Red Hat 4.8.5-4)), and have been trying to compile gcc 6.2.0 as downloaded from gnu website. The following is the error I got:

checking for x86_64-pc-linux-gnu-gcc... /home/xxx/gcc-6.2.0/build/./gcc/xgcc -B/home/xxx/gcc-6.2.0/build/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include   
checking for suffix of object files... configure: error: in `/home/xxx/gcc-6.2.0/build/x86_64-pc-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[2]: Leaving directory `/home/xxx/gcc-6.2.0/build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/xxx/gcc-6.2.0/build'
make: *** [all] Error 2

And looking into the x86_64-pc-linux-gnu/libgcc/config.log file:

configure:3435: /home/xxx/gcc-6.2.0/build/./gcc/xgcc -B/home/xxx/gcc-6.2.0/build/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include    -V >&5
xgcc: error: unrecognized command line option '-V'
xgcc: fatal error: no input files
compilation terminated.
configure:3446: $? = 1
configure:3435: /home/xxx/gcc-6.2.0/build/./gcc/xgcc -B/home/xxx/gcc-6.2.0/build/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include    -qversion >&5
xgcc: error: unrecognized command line option '-qversion'; did you mean '--version'?
xgcc: fatal error: no input files
compilation terminated.

What is happening here? I followed the procedure to "mkdir build;cd build" and then issued the configure command as below:

../configure --disable-multilib --enable-languages=c,c++ --with-system-zlib --with-default-libstdcxx-abi=gcc4-compatible
Peter Teoh
  • 6,337
  • 4
  • 42
  • 58
  • 1
    Possible duplicate of [Compilng libgcc xgcc error](http://stackoverflow.com/questions/16076660/compilng-libgcc-xgcc-error) – Oleksandr Kravchuk Sep 26 '16 at 00:14
  • no, not really. as you are see, my errors are "-V", -qversion, and even after modifying the configure, there are other errors arising from beyond line number 3600++. Let me solve the error in the same spirit of Philip's method. – Peter Teoh Sep 26 '16 at 00:27
  • The errors in configure are meant to happen, that's how configure works, it tries things until it figures out what works. The real issue is probably later in config.log. – Marc Glisse Sep 26 '16 at 07:46
  • you are right. I am just lazy wanting to see all the "error" going away in the config.log file soonest. – Peter Teoh Sep 26 '16 at 15:08

2 Answers2

0

With slight variation in error from that of (thanks to Oleksandr Kravchuk):

Compilng libgcc xgcc error

here below are my solution:

--- tmp/gcc-6.2.0/libgcc/configure  2016-04-11 15:45:35.000000000 -0400
+++ gcc-6.2.0/libgcc/configure  2016-09-25 15:59:21.611181908 -0400
@@ -3426,26 +3426,26 @@ See \`config.log' for more details." "$L
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" >&5
 set X $ac_compile
 ac_compiler=$2
-for ac_option in --version -v -V -qversion; do
-  { { ac_try="$ac_compiler $ac_option >&5"
-case "(($ac_try" in
-  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
-  *) ac_try_echo=$ac_try;;
-esac
-eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
-$as_echo "$ac_try_echo"; } >&5
-  (eval "$ac_compiler $ac_option >&5") 2>conftest.err
-  ac_status=$?
-  if test -s conftest.err; then
-    sed '10a\
-... rest of stderr output deleted ...
-         10q' conftest.err >conftest.er1
-    cat conftest.er1 >&5
-    rm -f conftest.er1 conftest.err
-  fi
-  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
-  test $ac_status = 0; }
-done
+#for ac_option in --version -v -V -qversion; do
+#  { { ac_try="$ac_compiler $ac_option >&5"
+#case "(($ac_try" in
+#  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+#  *) ac_try_echo=$ac_try;;
+#esac
+#eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
+#$as_echo "$ac_try_echo"; } >&5
+#  (eval "$ac_compiler $ac_option >&5") 2>conftest.err
+#  ac_status=$?
+#  if test -s conftest.err; then
+#    sed '10a\
+#... rest of stderr output deleted ...
+#         10q' conftest.err >conftest.er1
+#    cat conftest.er1 >&5
+#    rm -f conftest.er1 conftest.err
+#  fi
+#  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+#  test $ac_status = 0; }
+#done

 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */

So essentially I am just ignoring all the checks for "-qversion", "-V" and more. Moreover, later in the same configure script will give another "libisl" API not found error. Since I have I downloaded the libisl source code myself and compiled it to /usr/local/lib directly before, it seemed the gcc compilation is not picking up the new libraries.

Therefore I added "/usr/local/lib" line into the /etc/ld.so.conf file and did a "sudo ldconfig" thereafter.

Compilation proceeded to completion without error and testing seems good.

Community
  • 1
  • 1
Peter Teoh
  • 6,337
  • 4
  • 42
  • 58
0

I ran into the "[stage1-bubble] Error" because I wasn't following the proper procedure for building and installing gcc. For example, I had done configure on the source directory.

Here's what worked for building and installing gcc 8.1.0 on CentOS 7:

Some pre-requisites first:

yum install gcc-c++
yum install libgcc.i686
yum install glibc-devel.i686
yum install epel-release
yum install lbzip2
yum install wget
yum install flex

Download, build and install:

wget ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-8.1.0/gcc-8.1.0.tar.xz
tar -xvf gcc-8.1.0.tar.xz
cd gcc-8.1.0
./contrib/download_prerequisites
cd ..
mkdir objdir
cd objdir
$PWD/../gcc-8.1.0/configure --prefix=$HOME/GCC-8.1.0 --enable-languages=c,c++
make -j 3
make install

On my virtual machine the build takes several hours, even with -j option to take advantage of extra CPU cores.

If there is a build failure, for example a missing dependency, it's a good idea to wipe clean the 'objdir' directory and run make again.

By the way, these steps also worked to build more recent code from the Git repository, obviously with some minor modifications.

Nagev
  • 10,835
  • 4
  • 58
  • 69