GMP builds 64-bit binaries when asked for a 32-bit build

[Bruno Haible]

Hi,

It was already reported in
  https://lists.gnu.org/archive/html/bug-gmp/2008-04/msg00000.html
but still occurs with gmp 5.0.2.

* On a bi-arch Linux/glibc/PowerPC machine, where gcc produces 32-bit code
  by default, all packages configured with "./configure" produce
  32-bit code. EXCEPT GMP:
    $ file prefix-linux-ppc32/lib/libgmp.so.10.0.2
    prefix-linux-ppc32/lib/libgmp.so.10.0.2: ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, not stripped

* On a bi-arch Linux/glibc/SPARC machine, where gcc produces 32-bit code
  by default, all packages configured with "./configure" produce
  32-bit code. EXCEPT GMP:
    $ file prefix-linux-sparc32/lib/libgmp.so.10.0.2
    prefix-linux-sparc32/lib/libgmp.so.10.0.2: ELF 64-bit MSB shared object, SPARC V9, Sun UltraSPARC1 Extensions Required, relaxed memory ordering, version 1 (SYSV), dynamically linked, not stripped

* On a bi-arch MacOS X 10.5 machine, where gcc produces 32-bit code
  by default, all packages configured with "./configure" produce
  32-bit code. EXCEPT GMP:
    $ file lib/libgmp.10.dylib
    lib/libgmp.10.dylib: Mach-O 64-bit dynamically linked shared library x86_64

* On a bi-arch Solaris 11 machine, where gcc produces 32-bit code
  by default, all packages configured with "./configure" produce
  32-bit code. EXCEPT GMP:
    $ file prefix-solaris11-i386/lib/libgmp.so.10.0.2
    prefix-solaris11-i386/lib/libgmp.so.10.0.2: ELF 64-bit LSB dynamic lib AMD64 Version 1 [SSE2 SSE CMOV], dynamically linked, not stripped, no debugging information available

This is a major annoyance, because
  1) It's the opposite of what all other GNU programs do.
  2) The problem becomes apparent only during the builds of the next
     packages, which want to use gmp (like GNU guile for example).

The gmp manual documents this behaviour:
  http://gmplib.org/manual/ABI-and-ISA.html#ABI-and-ISA

The Autoconf manual mentions the common way of specifying the ABI by
-m64 or -m32 into $CC or $CFLAGS or $CPPFLAGS & $LDFLAGS:
  http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.68/html_node/Preset-Output-Variables.html
  "If an option affects multiple phases of the compiler, though,
   matters get tricky. One approach to put such options directly
   into CC, e.g., CC='gcc -m64'. Another is to put them into both
   CPPFLAGS and LDFLAGS, but not into CFLAGS."

The fundamental problem with this is that while the GNU Coding Standards [1]
are fuzzy about this issue, there are now two opposite ways to specify
the ABI.

IMO the GNU Coding Standards should state the recommended way to specify
the ABI, one way or the other.

Personally I find the GMP way the more obvious one: As a person who wants
to install a package, I decide first about the ABI and compiler brand,
then about the --prefix and --libdir, and finally only about the detail
options that I put into $CFLAGS or $CPPFLAGS. With the common way, a
small mistake in the choice of options leads to binaries in the wrong
(unexpected) ABI. The GMP way allows me to state the ABI directly and
pushes the choice of the particular compiler option (-m32 or -m64)
into the configure script. (This requires that the configure script
knows which option to use for which compiler. AC_PROG_CC_C99 and libtool
are already doing similar things.)

Bruno

[1] http://www.gnu.org/prep/standards/html_node/Configuration.html