egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

Hi Jim,

	I'd like to get your opinion on a problem I'm having on Irix6
when building egcs.  (This is cc'ed to the egcs list so everyone is
welcome to comment.)  I've summarized the main issues below. 

	The central problem arises when attempting to use libiberty.a
to link binaries.  Libiberty.a is built with the stage1 compiler.  The
problem I have occurs when I use cc for stage1.  By default, Irix6 cc
uses a different ABI than gcc so I can't link (o32 ABI) libiberty.a
with stuff built in stage2/3 (n32 ABI).

	Right now, I've made sure egcs never needs anything from
libiberty.a so none of the links with it pull in any of its modules. 
But if I make egcs use libiberty.a by nuking xmalloc from toplev.c, I
get the following error:

 > ld: FATAL 112: cannot link old 32-bit object with -n32 link:
 > 	../libiberty/libiberty.a(xmalloc.o).
 > collect2: ld returned 4 exit status

	Now if I use "cc -n32" for stage1, I can get it to work.  But
there are some problems with this.  I looked in egcs/config/mh-irix6
and found this:

 > # Specify the ABI, to ensure that all Irix 6 systems will behave the same.
 > # Also, using -32 avoids bugs that exist in the n32/n64 support in some
 > # versions of the SGI compiler.
 > CC = cc -32

	So it seems to be saying that there are bugs in n32 so we
can't use it?  Note the file already sets cc to use the -32 flag
(o32).  However egcs ignores this setting!  (Confused yet?)  It just
goes ahead and sets CC to either "cc" or "gcc" depending on what is
available.  I think this is a side effect of when we decided to let
autoconf choose CC.

	So we have the following issues:

1.  If Irix6 cc is used for stage1, should we add -n32 so when it
builds libiberty.a it is link compatible with stage2 binaries?

2.  Is "cc -n32" support truly buggy, or can we use it?

3.  If cc is used for stage1, libiberty.a is not optimized, it only
gets -g passed to it.  Do we care?  (This is a generic problem, not
an irix6 specific one.)

4.  Assuming we go with -n32, why is egcs ignoring the CC setting in
config/mh-irix6 and how do we fix it?  (This doesn't seem to be Irix6
specific either.)

5.  Maybe another way to go is to build libiberty.a for each stage.
We could build a symlink tree in egcs/gcc/libiberty and move it into
stageN so it is rebuilt every stage.  This would solve the linking
problem because libiberty.a would use the same ABI as the binaries it
is linked with.  It would also get us optimized versions of the
functions in there even when cc is used for stage1.

	Any insight you could provide would be appreciated.

		Thanks,
		--Kaveh

PS: Jeff already recommended against item 5 above and instead wants to
do something like passing a flag to make libiberty.a link compatible. 
However I am cautious because of the n32 bugginess comment above and
also because this means libiberty.a won't be optimized.  (I don't know
if that is significant though.) So I am seeking more information.  Thanks.
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.