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

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 11/6/06, Brooks Moses <brooks.moses@codesourcery.com> wrote:
> 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.

I believe Debian is still using glibc 2.3, so this is the same error I see with
SLES9.  Maybe you can figure out the correct fixinclude fiddling for this?

Richard.