Is "make bootstrap" known to be broken on mainline?

Brooks Moses brooks.moses@codesourcery.com
Mon Nov 6 08:35:00 GMT 2006


A couple of days ago, I tried to do a "make bootstrap" on an up-to-date 
copy of mainline, on a freshly-installed Debian Linux machine.  After 
several hours of anticipation, I got the following error:

> /home/brooks/gcc-trunk/build/./gcc/xgcc -B/home/brooks/gcc-trunk/build/./gcc/
> -B/home/brooks/bin-trunk/i686-pc-linux-gnu/bin/ -B/home/brooks/bin-trunk/i686
> -pc-linux-gnu/lib/ -isystem /home/brooks/bin-trunk/i686-pc-linux-gnu/include
> -isystem /home/brooks/bin-trunk/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H
> -I. -I../../../svn-source/libgfortran -I. -iquote../../../svn-source/libgfortran/io
> -I../../../svn-source/libgfortran/../gcc -I../../../svn-source/libgfortran/..
> /gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes
> -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2
> -c ../../../svn-source/libgfortran/io/unix.c  -fPIC -DPIC -o .libs/unix.o
> /tmp/cc8VFDuZ.s: Assembler messages:
> /tmp/cc8VFDuZ.s:4453: Error: symbol `fstat64' is already defined
> /tmp/cc8VFDuZ.s:4486: Error: symbol `lstat64' is already defined
> /tmp/cc8VFDuZ.s:4625: Error: symbol `stat64' is already defined
> make[3]: *** [unix.lo] Error 1
> make[3]: Leaving directory `/home/brooks/gcc-trunk/build/i686-pc-linux-gnu/libgfortran'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/brooks/gcc-trunk/build/i686-pc-linux-gnu/libgfortran'
> make[1]: *** [all-target-libgfortran] Error 2
> make[1]: Leaving directory `/home/brooks/gcc-trunk/build'
> make: *** [bootstrap] Error 2

I understand from conversation on IRC that this is a known problem, 
related to one of the patches checked in recently that's the subject of 
some discussion.

Is this correct?

If so, is there a reasonable workaround for this that will enable me to 
bootstrap-test the Fortran changes that I'm currently working on, so 
that this isn't holding up everything I'm doing?  Ideally, a workaround 
that will not require me to track the relevant conversations here to 
find out when to back out the workaround, but I suppose I can't be too 
picky.

Thanks,
- Brooks



More information about the Gcc-patches mailing list