[Bug bootstrap/12396] build of gcc 3.4 20030920 fails during compilation of fixincl.c

[p dot van-hoof at qub dot ac dot uk]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12396



------- Additional Comments From p dot van-hoof at qub dot ac dot uk  2003-09-27 23:05 -------
Subject:  build of gcc 3.4 20030920 fails during compilation of fixincl.c

I think I finally got to the bottom of this. At the beginning of the libiberty
configure script it is searching for a posix compatible shell, and reruns
itself as /bin/bash. The "set" command in that shell adds the extra $ (see
below). It appears that Solaris 7 doesn't come with a pre-installed bash
shell, so it seems plausible that on Kaveh's machine the configure script will
find a different shell. That could be an explanation why his compilations
succeed. Here are some details:

scooby# cat bashtest
#! /bin/bash
ac_cv_prog_CPP='gcc -E'
set
scooby# ./bashtest | grep ac_cv_prog_CPP
ac_cv_prog_CPP=$'gcc -E'
scooby# /bin/bash --version
GNU bash, version 2.05.0(1)-release (sparc-sun-solaris2.9)
Copyright 2000 Free Software Foundation, Inc.


When the libiberty configure script finishes, the config.cache will contain

ac_cv_prog_CPP=${ac_cv_prog_CPP=$'gcc -E'}

When the next configure script reads this in and rewrites the config.cache at
the end, it will transform this into

ac_cv_prog_CPP=${ac_cv_prog_CPP='$gcc -E'}


I am not sure why bash behaves differently under Solaris and Linux, but since
bash will be installed by default on all Solaris 8 and 9 systems, I am sure
that all those users will not be able to compile gcc with the current version
of the configure scripts.