configure issue during make of avr-elf

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

Hi,

One of the RTEMS GSoC students is running into a
problem building avr-elf toolset as a precursor
to modifying avr-rtems.  Josh is getting an
error which indicates a configure inconsistency.
I have tried building this toolset on two
different machines and have no problems.
I even sent him a script which starts by
checking binutils, gcc, and newlib out of cvs/svn,
setting up the tree and building it.  It still fails
for him and works for me. I see nothing in our
environments (both Fedora 10) to hint at the problem.


target is avr-elf with newlib.

Here is the error from the make

Configuring in avr-elf/libgcc
configure: loading cache ./config.cache
configure: error: `CC' has changed since the previous run:
configure:   former value:  `/home/cain/avr-tools/gcc/./gcc/xgcc 
-B/home/cain/avr-tools/gcc/./gcc/ -B/home/cain/avr-install/avr-elf/bin/ 
-B/home/cain/avr-install/avr-elf/lib/ -isystem 
/home/cain/avr-install/avr-elf/include -isystem 
/home/cain/avr-install/avr-elf/sys-include   '
configure:   current value: `/home/cain/avr-tools/gcc/./gcc/xgcc 
-B/home/cain/avr-tools/gcc/./gcc/ -nostdinc 
-B/home/cain/avr-tools/gcc/avr-elf/newlib/ -isystem 
/home/cain/avr-tools/gcc/avr-elf/newlib/targ-include -isystem 
/home/cain/src/gcc-svn/trunk/newlib/libc/include 
-B/home/cain/avr-tools/gcc/avr-elf/libgloss/avr 
-L/home/cain/avr-tools/gcc/avr-elf/libgloss/libnosys 
-L/home/cain/src/gcc-svn/trunk/libgloss/avr 
-B/home/cain/avr-install/avr-elf/bin/ 
-B/home/cain/avr-install/avr-elf/lib/ -isystem 
/home/cain/avr-install/avr-elf/include -isystem 
/home/cain/avr-install/avr-elf/sys-include   '
configure: error: in `/home/cain/avr-tools/gcc/avr-elf/libgcc':
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm ./config.cache' and 
start over
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory `/home/cain/avr-tools/gcc'

I see an old message that this can be worked around by a
hack in the top level Makefile.in but the file looks very
different now and this message didn't explain the failure.

http://sourceware.org/ml/newlib/2006/msg00472.html

Any ideas on this one?

--joel sherrill
RTEMS