config.guess and $CC

[Bruno Haible]

[Sorry for the CC to bug-gnulib, but I want this discussion to be public
 and I don't see archives of the config-patches list anywhere.]

Hi Ben,

On a bi-arch system (i.e. a system that can execute 32-bit mode binaries and
64-bit mode binaries), what is the expected behaviour of config.guess?
Should it return different triplets for CC="gcc -m32" and CC="gcc -m64",
or the same?

The reason for this question is:

1) The current state of config.guess.
   $CC is taken into account for determining the ABI on
     NetBSD, RISCOS, HP-UX/hppa, HI-UX, Linux/arm, Linux/mips, Linux/x86.
   $CC is not taken into account for determining the ABI on
     Linux/sparc64, Linux/x86_64, Linux/PowerPC64, Linux/IA64 (vs. /x86).

2) GNU clisp has an autoconf macro CL_CANONICAL_HOST_CPU that performs extra
   checks in order to distinguish 32-bit from 64-bit compilations:

case "$host_cpu" in
changequote(,)dnl
  mips )
    AC_CACHE_CHECK([for 64-bit MIPS], cl_cv_host_mips64, [
    AC_EGREP_CPP(yes,
      [#if defined(_MIPS_SZLONG)
      #if (_MIPS_SZLONG == 64)
      /* We should also check for (_MIPS_SZPTR == 64), but gcc keeps this at 
32. */
        yes
      #endif
      #endif
      ], cl_cv_host_mips64=yes, cl_cv_host_mips64=no)
    ])
    if test $cl_cv_host_mips64 = yes; then
      host_cpu_instructionset=mips64
    fi
    ;;
  dnl On powerpc64 systems, the C compiler may still be generating 32-bit code.
  powerpc64 )
    AC_CACHE_CHECK([for 64-bit PowerPC], cl_cv_host_powerpc64, [
    AC_EGREP_CPP(yes,
      [#if defined(__powerpc64__) || defined(_ARCH_PPC64)
        yes
      #endif
      ], cl_cv_host_powerpc64=yes, cl_cv_host_powerpc64=no)
    ])
    if test $cl_cv_host_powerpc64 = yes; then
      host_cpu_instructionset=powerpc64
    else
      host_cpu_instructionset=powerpc
    fi
    ;;
  dnl UltraSPARCs running Linux have `uname -m` = "sparc64", but the C compiler
  dnl still generates 32-bit code.
  sparc | sparc64 )
    AC_CACHE_CHECK([for 64-bit SPARC], cl_cv_host_sparc64, [
    AC_EGREP_CPP(yes,
      [#if defined(__sparcv9) || defined(__arch64__)
        yes
      #endif
      ], cl_cv_host_sparc64=yes, cl_cv_host_sparc64=no)
    ])
    if test $cl_cv_host_sparc64 = yes; then
      host_cpu_instructionset=sparc64
    else
      host_cpu_instructionset=sparc
    fi
    ;;
  dnl On x86_64 systems, the C compiler may still be generating 32-bit code.
  x86_64 )
    AC_CACHE_CHECK([for 64-bit x86_64], cl_cv_host_x86_64, [
    AC_EGREP_CPP(yes,
      [#if defined(__LP64__) || defined(__x86_64__) || defined(__amd64__)
        yes
      #endif
      ], cl_cv_host_x86_64=yes, cl_cv_host_x86_64=no)
    ])
    if test $cl_cv_host_x86_64 = yes; then
      host_cpu_instructionset=x86_64
    else
      host_cpu_instructionset=i386
    fi
    ;;
  *)
    host_cpu_instructionset=$host_cpu
    ;;
esac

3) On MacOS X 10.5 systems, "uname -m" returns "i386". But the system is
64-bit, and "gcc -m64" generates x86_64 programs that run perfectly fine
natively.

A user on such a platform struggled for *hours* to get a program compiled
with "gcc -m64", because in this situation, config.guess returns no
indication of a 64-bit CPU:

  address@hidden:~/devel/cln-1.2.0]$ export CC="gcc -m64"
  address@hidden:~/devel/cln-1.2.0]$ sh autoconf/config.guess
  i386-apple-darwin9.1.0

If config.guess returns such a result, it is really not obvious that the
user has to use
  ./configure --host=x86_64-apple-darwin
in order to get the program compiled.

Recall that this is a *native* build, not a cross build. I'd say, it's a
config.guess bug. config.guess should return "i386-apple-darwin9.1.0" if
the compiler generates 32-bit object code and should return
"x86_64-apple-darwin9.1.0" if the compiler generates 64-bit object code.

Bruno