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

[Alexandre Oliva]

On Mar 15, 2003, Andreas Jaeger <aj@suse.de> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> This is the last patch of the batch, hopefully keeping the o32 port
>> functional, while enabling people to try to build n32 and n64.  I

> Hopefully? I require that you test it and fix any breakage.

Sure.  The plan was to test before actually committing this patch, but
this requires this patch to go in last.

>> still intend to make some changes to the top-level configuration.  In
>> particular, I remember Roland didn't quite like the introduction of
>> flags_for_cc, so I'm probably going to take that out of the top level
>> and move it into linux/mips/configure.in or so.

Unfortunately, this can't be done.  We must really set CC/CFLAGS to
the proper value before we run any configure tests whatsoever,
otherwise results may end up incorrect.

However, come to think of it, the only reason I found for
flags_for_cc, and for introducing the configuration triplets that
weren't accepted in config.{guess,sub}, was that Uli had told me that
detecting the ABI from preprocessor implicit defines was not
acceptable.  Originally, I was thinking of using always
mips64{,el}-linux-gnu, and expecting the user to add -mabi={n32,32,64}
to CFLAGS to specify the ABI settings.  Would this solution be
acceptable?

This is not to say that it would make the whole thing cleaner.  On the
contrary: it would require even more hackery in the top level
configure, which I'd rather avoid, since we'd then have to move part
of the machine-specific configuration past AC_PROG_CPP.  This couldn't
be moved to mips- or mips64-specific configure since it would be too
late at that point to modify the base machine name to the one implied
by the preprocessor settings.

I guess this means I'm going to need flags_for_cc or something
similar.  I might just add -mabi=/-E[BL] to CPPFLAGS or CFLAGS, which
feels odd but should work.

> The sysdeps/ fixes are ok from my side,

Thanks, I'll put them in along with the top-level patch, when the rest
goes in and the (revised) top-level is approved.

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