Irix6 bootstrap fails, fundamental problem w/libiberty built with cc

[Kaveh R. Ghazi]

	When I bootstrap egcs on on mips-sgi-irix6.2 using cc for stage1,
I get the following:

 > stage1/xgcc -Bstage1/ -B/usr/local/mips-sgi-irix6.2/bin/ -DIN_GCC -W
 > 	-Wall -O2 -g -o ../jc1 parse.o class.o decl.o expr.o constants.o
 > 	lang.o typeck.o except.o verify.o zextract.o jcf-io.o jcf-parse.o
 > 	mangle.o jcf-write.o buffer.o jcf-depend.o jcf-path.o `cat
 > 	../stamp-objlist` ../../libiberty/libiberty.a
 > ld: FATAL 112: cannot link old 32-bit object with -n32 link:
 > 	../../libiberty/libiberty.a(obstack.o).
 > collect2: ld returned 4 exit status
 > make[3]: *** [../jc1] Error 1

	The problem is that parts of jc1 use obstack.  The gcc built
obstack.o is not linked with, so the copy from libiberty.a is used.

	This could easily be solved by adding ../obstack.o to the link
of jc1.  (That one is built from the symlinked copy of obstack.c in
the gcc/ directory and is built with stageN/gcc so it is link
compatible.)  But this is not the fundamental issue.


	The issue IMHO is that all of libiberty (not just obstack.o)
built with stage1 cc may not be compatible with stage>=2 files built
with gcc.

	This throws a monkey wrench into plans for eliminating cruft
like local copies of xmalloc etc, and getting it all from libiberty.a.

	I think we need to either somehow make sure object files built
in stage1 are compatible with gcc, or rebuild libiberty.a at each
stage.

	This is not a recent problem, its been happening for a while and
I worked around it in my local sources.  However I'd like to begin work
on using libiberty more extensively and this is in the way.  So unless
I've bungled something in my bootstrap procedure, I think this is a real
snag. 

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.