canonical triple of SPARC/Solaris changed

[Bruno Haible]

Hi,

With the newest config.guess, GNU libffcall 2.x no longer builds out of the
box on SPARC / Solaris 10 with CC="cc -xarch=generic64 -O".

The reason is that config.guess, which used to return 'sparc-sun-solaris2.10',
now returns 'sparcv9-sun-solaris2.10'.

1) This is a regression. The platform exists for 20 years, and there is
   no good reason to change the triple of ANY platform after it is in
   production for more than 1 year.

2) There are already Autoconf macros for determining the ABI generated by
   the compiler. And there are Autoconf macros for determining whether
   the compiler generates 32-bit or 64-bit code. Such a macro is contained
   in Gnulib, module 'host-cpu-c-abi':
   
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=m4/host-cpu-c-abi.m4

3) Different packages have different needs, in this area.

   * Some package may only want to know whether sizeof (void*) == 4 or == 8.
     Thus it will treat the two 32-bit ABIs on x86_64 (commonly denoted as
     'i386' and 'x32') the same. Similarly on MIPS, where the 'o32' and 'n32'
     ABIs both have sizeof (void*) == 4.

   * Some package wants an ABI identifier, in order to know what kinds of
     binaries can be linked together and what binaries cannot.
     E.g. on x86_64, i386 libraries, x32 libraries, and x86_64 libraries
     are mutually link-incompatible. So, for these kinds of packages, there
     will be 3 possible answers on x86_64 systems.

   * Some package (like GNU gmp) wants an ABI identifier that includes an
     indication regarding the instruction set. For example, 'arm' has
     armv5, armv6, armv7 (and many more) instruction sets.

   * Some packages want to distinguish the 32-bit PowerPC ABI on Mac OS X,
     the 32-bit PowerPC ABI on AIX, and the 32-bit PowerPC ABI on Linux and
     *BSD OSes. Namely, packages that have hand-written assembly language
     sources; the assembler pseudo-ops differ.

   Since different packages have different needs in this area, it makes no
   sense to try to put the result into the config.guess triple. Such an
   approach will NEVER be able to satisfy the needs.

   The only approach that makes sense is an Autoconf macro for each of
   the purposes/needs.

The change that causes this is from 2019-01-03, commit
5fe51ffd1b2933fce914b0be5a651ee7ec21e6d2 .

I kindly suggest to revert this change.

Bruno