This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
IRIX6 Makefiles
- To: Gavin Romig-Koch <gavin at cygnus dot com>
- Subject: IRIX6 Makefiles
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Tue, 11 Jul 2000 11:31:21 -0700
- Cc: Jim Wilson <wilson at cygnus dot com>, gcc-bugs at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
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