Improving GMP configure

[Torbjorn Granlund]

nisse at lysator.liu.se (Niels Möller) writes:

  Torbjorn Granlund <tg at gmplib.org> writes:
  
  > * Add a mechanism for using a default ABI (as already discussed):
  >
  >    o Choose compiler according to current rules, then figure out that
  >      compiler's default ABI.
  >
  >    o Problem 1: Different compilers might have different default ABIs,
  >      which can lead to surprises and still require user's to pass
  >      special options.
  
  One of the main points of this feature is that the resulting
  library will be compatible with other packages built with default
  options. So I'd advocate to let the standard AC_PROG_CC choose the
  compiler here (since it seems a bit tricky to detect the default ABI of
  that compiler, and then figure out what flags to pass to get a different
  compiler to use that same ABI).
  
  Under what circumstances do you want a different compiler than
  AC_PROG_CC?
  
I didn't say that.  I don't know if the rejection mechanism are inside
AC_PROG_CC or if the backtrack AC_PROG_CC from external tests.  But we
do reject compilers today, based on known bugs, tested from via
acinclude.m4.

  > * When configure promotes a compiler from a generic name like 'cc' to
  >   Sun's 'acc' or IBM's xlc, it drops cc_cflags.  This happens e.g., for
  >   none-ibm-aix6.1.  (This is probably not hard to fix.)
  
  I'm not following you here. But I'm not very familiar with these
  configure features.
  
The result is that -O is not passed.  (This is how the x & 0 == x bug
was triggered.)

  >    o Deprecate none-*-* and add an option --disable-assembly.
  
  Makes sense to me. The nettle configure script calls that option
  "--disable-assembler"; I don't know English well enough to say which
  name is best, but some consitency would be nice. Any other (GNU)
  packages that have a configure option liek that?
  
To me, an assembler is a program that takes assembly code as input.
(We could allow both --disable-assembler and --disable-assembly.)

  > * We don't detect and reject hopelessly broken compiler like gcc 4.3.2
  >   or the buggy xlc compilers.  Perhaps we should simply detect them,
  >   unless somebody can come up with a feature test (that does not require
  >   target machine execution).
  
  What type of bugs? If it's miscompilation, and you don't want to execute
  any target code, I guess one would have to somehow examine generated
  assembler. Sounds possible but tricky to me.

We do that in some cases now.  We can also do 'xlc -qversion | grep
10.0' or whatever if we know just a specific version is bad.

-- 
Torbjörn