ABI defaults

[Torbjorn Granlund]

  > It is not clear how to address this.
  
  I suspect we need two quite separate cases in configure.in, doing things
  in different order. For the ABI=default case, things should be fairly
  simple:
  
    * Do a standard AC_PROG_CC,
  
    * do AC_CHECK_SIZEOF on various types,
  
    * run the script to figure out the ABI,
  
    * then go on to the part of the configure script which selects the
      assembly path.
  
The part of the configure script which selects assembly path also sets
up ABI stuff, and that part needs to be executed also in the non
ABI=default case.  We cannot have a if else fi thingy.

Perhaps we should split configure.in into several pieces, allowing us to
invoke a part from different places?  It is also a very hard-to-read
file, and splitting it might be a good idea irrespective of the
ABI=default changes.

  Right? What else is there which depends on the ABI? At least for a
  start, I don't think we need to do anything clever with CFLAGS, except
  maybe apend some extra optimization flags for some known compilers.
  
Yes, we need to set CFLAGS exactly as cleverly as when a user selects
ABI explicitly or when ABI defaults to the "best choice".

  BTW, do you have a list of which platforms have more choices of ABI than
  simply 32-bit or 64-bit? A quick look in configure.in turns up:
  
  HPPA: 1.0, 2.0n, 2.0w,
  
  MIPS64: n32, o32, 64
  
  PPC64: Unclear, I see 32, mode32, mode64, aix64, but I'm not sure which
         can coexist on the same platform.
  
These are the ones I am aware of.  I am not sure about PPC, but I think
we might have 3 ABIs there on ELF systems (i.e., GNU/Linux, and BSD).
(mode32 and mode64 are 64-bit processors running in 32-bit mode and
64-bit mode, 32 is a 32-but processor.)

-- 
Torbjörn