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

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

 > From: Jim Wilson <wilson@cygnus.com>
 > 
 > If we add -n32, people that have old versions of the SGI C compiler won't
 > be able to build egcs anymore.

	Right.


 > However, I suspect that few people have
 > these old and buggy SGI C compilers anymore.


	I think historically we've tried to support as many cc setups as
we could.  (Note how old K&R compilers are, yet we still support them.)
I'm not enthusiastic about hosing users of older (pre-7.1) SGI compilers.



 > The config/mh-irix6 stuff was inherited from Cygnus when we adopted the
 > Cygnus top level configuration directory.  This stuff stopped working for
 > Cygnus when Ian Taylor fixed a toplevel configure bug.  That was sometime in
 > 1997 I believe.  I don't think anyone has seriously looked at this issue, but
 > my feeling is that we can't make CC definitions in config/m*-* files work
 > anymore, because this is inconsistent with other features of configure.
 > And for the same reasons, setting CFLAGS there won't work either.  It is
 > probably a bit of work to fix this.  I think we would need to create a new
 > toplevel host dependent compiler option variable, which can be set in a
 > config/m*-* file, and then modify configure and/or Makefile to pass it along
 > with CFLAGS to the host CC.
 > 
 > My recollection of the exact problem with the toplevel configure file is
 > hazy, but it has something to do with the fact that CC and CFLAGS are allowed
 > to be specified by the user.  Hence we get them from the user if the user
 > specified them, otherwise we use gcc if it exists, otherwise we default to cc.
 > There is a complication here when reconfiguring after an update, e.g.
 > 	./config.status --recheck
 > which needs to get CC from the Makefile, because there might be a user
 > specified value there from the original configure command.  The changes to
 > make this work right are what caused the config/m*-* file to stop working.


	Eww, gross. :-)  But thanks for the info.



 > 
 > Hmm, maybe we can make configure default to DEFAULT_CC instead of cc, and
 > then let a config/m*-* file override DEFAULT_CC?  This probably requires fixing
 > the code that re-extracts CC from the Makefile though.


	Yes I suppose.  I think something similar is done in the emacs
sources by setting NON_GNU_CC and NON_GNU_CFLAGS.



 > 
 > You didn't mention it, but there is also a gcc/config/mips/x-irix6 file which
 > specifies `cc -32'.  This part is from gcc2, and this part broke when gcc2
 > adopted autoconf.  Similarly, I don't think we can make this work anymore
 > without using a different makefile variable.  We have X_CFLAGS, but I don't
 > know whether that works anymore either.  I suspect it does work, however,
 > this doesn't help with libiberty, it only helps with gcc.

	Right, we have to solve it for both or it does not good
('cause we have to ensure libiberty.a is link compatible with gcc.)

 > 
 > 	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.
 > 
 > We already have an N32 libiberty in $target/libiberty.  This is needed because
 > libstdc++/libio use libiberty, and they will be N32 code.  This does not get
 > built until after gcc has bootstrapped currently.  It might be possible to
 > build it after the stage1 gcc build, and then link the stage2/stage3 compilers
 > with it.  This would require rewriting the bootstrap rule in the toplevel
 > Makefile.
 > 
 > Jim

	I'm not thrilled with a cc -n32 solution, since it screws some
pre-7.1 SGI users.  I also think it would be a lot of work to get the
cc -n32 via config/mh-* working given the description you wrote above. 
I am not cygnus-configure literate, so it would be a real pain to
implement. 

	IMHO, the right way to go is to rebuild libiberty at each stage
in the gcc directory.  Ignore all the $target/libiberty stuff.  Instead,
in the build process of gcc, we can run symlink-tree on ../libiberty and
build it similar to how we build the language subdirs (except we do it
before anything else in the stage.) Then link everyone with that copy of
libiberty.a.  In between stages, we move the symlink-tree libiberty
directory into stageN so it gets rebuilt.  (Also we can add it to the
make compare rule for added consistency checking.)

	This is something we'll have to do anyway to get canadian
crosses working since we have to build a separate libiberty.a with
$CC_FOR_BUILD as well as one with $CC.

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