Re: enable n32 and n64, and move o32 into mips/mips32

[Alexandre Oliva <aoliva at redhat dot com>]

On Mar 18, 2003, Roland McGrath <roland at redhat dot com> wrote:

> The builder is always expected to provide the baseline CC and CFLAGS
> necessary to produce code for the platform.

The platforms are mips64-*-linux-gnu and mips64el-*-linux-gnu.  They
both support 3 different ABIs.  There is precedent to adding ABI
specifications to the configure tuples, but it AFAIK it has always
been the case that either the ABIs could not be active in the same
system (ppc-*-linux-gnu versus ppc-*-linux-gnu-altivec) or they were
introduced along with an ISA revision of an architecture, introducing
a new ABI while still maintaining the ability to run code of the
earlier ISA, using the old ABI (sparc/sparc64, x86/x86_64,
s390/s390x), such that the machine name was enough to give the
distinction.  In the case of mips, with the introduction of 64-bit
ISAs, two new ABIs were introduced, so mips64-linux-gnu alone doesn't
imply any ABI.

I find that supporting ABIs in the triplet names is fine, but not
adding the corresponding ABI-selection flags to the flags passed to
the compiler, expecting the user to supply them, may lead to silent
generation of incorrect code.  Expecting the user to add any
ABI-choosing flags to say CFLAGS, OTOH, enables us to use the platform
name as the configuration triplet, which is good for cross compiler
names to be guessed correctly, and having glibc detect the ABI from
the compiler helps prevent errors.

> The sysdeps selections are based on the tuple out of config.sub, and
> that's as it should be.

config.sub has no notion of mips64-*-linux-gnu ABIs, and the
maintainer of config.sub has explicitly rejected such a notion, since
the configuration tuple is *not* the ideal place to specify the ABI.

> If you have a different ABI, that is a different configuration tuple
> for the purposes of GNU configure scripts.

This is not true.  There are no such tuples as say
mips-sgi-irix6.5-n32 or mips-sgi-irix6.5-n64.  The platform name is,
and has always been, mips-sgi-irix6.5.  Programs that care about
differences in the ABI are supposed to get the ABI information from
the compiler, if they can't be built for more than one ABI at a time,
or to support them all, like GCC and multilib-capable packages do.
multilibs are actually a good example of a situation in which multiple
ABIs don't require any changes to configure triplets.  The sh-*-elf
tuple supports dozens of ABIs, but the configure triplet is still the
same.  newlib, libstdc++-v3 and all other target libraries cope with
the different ABIs of the same tuple by detecting the ABI the command
$CC $CPPFLAGS $CFLAGS generates code for.  Why should glibc impose
different requirements?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva at {redhat dot com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva at {lsd dot ic dot unicamp dot br, gnu.org}
Free Software Evangelist                Professional serial bug killer