Dennis Clarke wrote:
> > The reason for the failure is that somehow the CFLAGS for the bootstrap
> > Sun compiler are getting passed to the just-built xgcc during building
> > of libgcc.
>
> That is so very strange. I have never seen that before.
I just checked the diffs for the entire tree of 4.2.1 -> 4.2.2 and aside
from the license update to GPL3, there are actually few changes. I
couldn't see any changes that touch this part of the build system that
passes flags down to the various stages. So I keep coming back to some
kind of environmental difference between your working 4.2.1 bootstrap
and the failing 4.2.2.
> > I suspect an environmental problem. Do you have
> > CFLAGS_FOR_TARGET set by any chance?
>
> No Sir I do not.
Hmm. How about CFLAGS? I notice in your build log that very early in
the toplevel configure there's this line of output:
checking whether the C compiler (cc -xstrconst -xildoff -xarch=v7
-xcode=pic32 -xlibmieee -xlibmil -Xa -xregs=no%appl ) works... yes
...where the corresponding line in configure is:
echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS)
works""... $ac_c" 1>&6
...and later on in Makefile.in:
CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET)
...which would seem to explain how it makes its way into
CFLAGS_FOR_TARGET where goes on to cause problems. (The logic of this
bit of code -- setting the gcc flags from the bootstrap compiler CFLAGS
-- seems suspect in the case of non-gcc bootstrap compiler, however this
has been done this way since the beginning of time as far as I can tell
from the version history.)
If CFLAGS isn't set in the environment, then can you grep the generated
Makefiles in your build tree for this string to see if they're
substituted into any variables? Perhaps something like:
find /opt/build/gcc-4.2.2-build -name Makefile | \
xargs grep -F -n -e '-xstrconst -xildoff -xarch=v7'
Brian
