ABI defaults

[Niels Möller]

Torbjorn Granlund <tg at gmplib.org> writes:

> I think CC="gcc -m32" or CC="gcc -maix64", etc, would be the correct
> way.  If we recommend using CFLAGS, people will tend to switch off
> optimisation; it would be weird if we overrode CFLAGS, since then there
> would be no way to, say, make a debug build without optimisation.

I'm slowly starting to think on how to organize this. Some initial
thoughts:

  * AC_PROG_CC in current autoconf has on optional argument giving the
    list of compilers to look for. So maybe we should use
    AC_PROG_CC($cclist). Using AC_PROG_CC with an argument seems to skip
    some of the processing done when it is used without argument,
    including blacklisting of /usr/ucb/cc and the handling av
    ac_tool_prefix, I'm not sure this is a problem.

  * I'm not sure how gmp's blacklisting of broken compilers work. To use
    AC_PROG_CC as above, we'd clearly need to prune cclist before
    calling AC_PROG_CC.

  * Current configure.ac uses AC_PROG_STDC. If we don't use c99 features
    (and I don't think we do), this is unnecessary since AC_PROG_CC
    implies AC_PROG_CC_C89.

  * Putting something like gcc -m32 on cclist, or in the argument to
    AC_PROG_CC won't work, since these lists are whitespace separated.

Would the following organization of things do?

1. Big host switch. Sets abilist and cclist, and sets xx_path, xx_aa_cflags
   etc for each abi (cclist is appearantly abi independent).

2. Prune cclist, removing known bad compilers (mostly depending on
   version; if a compiler is known to be broken for a particular
   platform, it should never be added to cclist in the first place).

3. If ABI=default: select compiler using AC_PROG_CC($cclist), figure out
   ABI. Fail if compiler known broken. Set path, CC, CFLAGS, etc.

4. Else, select ABI. Obey user's ABI setting, and fall back to the "best"
   ABI if not specified by the user. (I still find automagically
   selecting the "best" ABI of very questionable value). Select compiler
   and compiler flags, obeying user's CC and CFLAGS. Fail if the
   resulting compiler is known broken or can't support the given ABI.

5. Further modifications of path (enable_assembly, fat builds, nails,
   ...)

I'm not sure where to add flags such as -m32 (except in the ABI=default case, where
configure shouldn't care).

* If the user includes -m32 in CC or CFLAGS, and GMP's configure thinks
  a 64-bit ABI is appropriate, should it remove the flag (probably not)?
  Should configure interpret the flag, and realize that the user wants
  to build for the 32-bit ABI?

* If the user sets CC=gcc but doesn't set CFLAGS, and configure wants an
  -m32 flag, should it be added to CFLAGS?

* If the user sets CFLAGS but not CC, and configure wants an -m32 flag,
  should it be added to CC rather than CFLAGS?

For optimization, warning and debug flags and the like, it makes sense
to say that if the user have set CFLAGS, use those flags as is with not
additions or other tweaks. But -m32 is not if this kind, and it makes
some sense to say that it belongs to CC rather than CFLAGS. But on the
other hand, if the user has set CC, should we really modify that value
adding -m32 to it?

I think it might make sense to output xx_aa_abicflag from the big switch,
then one can both look for that flag in the user's input, and one can
add that flag to CC while putting the rest of the xx_aa_cflags in CFLAGS
only if CFLAGS is not set. (Is it always a single flag to select the ABI?)

> No, I don't think all distinctions we want can be made.  I would like
> this code to be resilient, depending on sizes would meet these goals.  I
> am a bit weary about parsing 'file foo.o' output, which is the only
> other ABI detection method of which I am aware.

For parsing foo.o, do all relevant object format have a reasonable ABI
marking in the header?

One can of course also look at preprocessor symbols. If there's only a
few systems where examining sizes of basic types is not enough, that
could be practical.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.