3.1 bootstrap fails on sparcv9-sun-solaris2.8

[Brad Lucier]

> 
> On Apr  9, 2001, Brad Lucier <lucier@math.purdue.edu> wrote:
> 
> > ../configure sparcv9-sun-solaris2.8 --prefix=/pkgs/gcc-2.96 --enable-checking=no
> 
> > stage1/xgcc -Bstage1/ -B/pkgs/gcc-2.96/sparcv9-sun-solaris2.8/bin/  -DIN_GCC  -D
> > SVR4  -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -
> > Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H  -o cc1 \
> >         c-parse.o c-lang.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-c
> > onvert.o c-aux-info.o c-common.o c-format.o c-semantics.o c-dump.o libcpp.a  mai
> > n.o libbackend.a obstack.o       ../libiberty/libiberty.a
> > ld: elf error: file ../libiberty/libiberty.a(obstack.o): elf_getshdr: Request er
> > ror: class file/memory mismatch
> 
> Hmm...  This is indeed a problem.  You won't be able to link the
> 32-bit libiberty with the 64-bit object files generated by the stage1
> compiler.
> 
> The solution I see is for you to `make all', since this is, in a
> sense, a cross compiler, install the resulting compiler, and only
> then, if you wish, use this 64-bit compiler for a bootstrap.

Aren't we going about this all the wrong way?  I just want to
build a nice, 32bit, compiler that can happen to generate 64-bit code
and link to 64-bit libraries when I give the right options.  It seems
to me that this should be possible, or even straightforward.

Brad