IRIX6 Makefiles

Mark Mitchell mark@codesourcery.com
Tue Jul 11 11:32:00 GMT 2000


Gavin --

  There's something distinctly odd about the configure process on
IRIX6.

  Because of historical bugs in IRIX cc, we have in the toplevel
config/mh-irix6:

  # 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

Correspondingly, in gcc/config/mips/x-iris6, we have:

  # We force the use of the O32 ABI for two reasons.
  # 1) For consistency, because some versions of Irix 6 default to the O32 ABI
  #    and some versions default to the N64 ABI.
  # 2) To avoid SGI compiler bugs.  The v6.x and v7.0 compilers from SGI have
  #    bugs that cause gcc to be miscompiled when the N32 or N64 ABIs are used.
  #    The O32 ABI is known to be OK.
  CC = $(OLDCC)
  OLDCC = cc -32

OK, so far so good.  The point of all this is to try to force the
build system to use `cc -32' for building stage1.

  But, if you have GCC in your path, the toplevel configure finds it.
And because its sed replacements happen *after* the host fragment is
inserted in the Makefile, the top-level Makefile ends up with:

  CC = gcc

even though the GCC Makefile has the `CC = $(OLDCC); OLDCC = cc -32'
bit.

  Now, everything is sort-of OK if you do a bootstrap because the
CC=gcc is passed down to the GCC Makefile, meaning that you build
everything with GCC.  But heaven help you if you go back to the GCC
directory and say make after making a change; you get the `cc -32'
stuff, and since your initial build was done with GCC, which defaults
to the N32 object model, not the o32 object model, you're hosed.

  I think that we could just lose the O32 override bits at this point.
Or, we could make the top-level configure leave teh attempted override
of CC alone.  Or, we could have the top-level configure notice whether
or not you're using GCC, and old add -32 in that case.

  I think the GCC-specific override should go in any case; that's just
inviting the kind of skew that's present between the top-level and the
GCC subdirectory.

  Thoughts?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


More information about the Gcc-bugs mailing list